The most significant development since my last post is the adoption of a somewhat standard method of separating different versions of our test application. We needed a way to have different iterations of the application, and git provides this natively as a version control tool.
Until this point I had been pretty comfortable using the basic git commands like “commit”, “push”, and “pull”, but this becomes routine and I would typically be using my own projects and committing to “main”. The stakes were low.
In this case, I am providing instructions, not only for my team members but also for anyone in the future who wants to test out the project for themselves. The naming conventions and steps don’t have to be “easy,” but I still need to document them. We also decided to include either a document or web page that guides a user through set up and installation, as well as exploring all of the vulnerabilities of the application.
I always appreciate good documentation when I start using a new tool, so I am challenging myself to be clear and concise with the write-ups and instructions for this project. The repository is already somewhat large and convoluted, with SQL scripts, server code and front-end code all occupying the same space. I am almost obsessive when it comes to this kind of documentation and I can see that I will need to place some guidelines of my own to avoid going down any documentation rabbit holes and wasting a bunch of time.
In the end, some of the naming conventions and git practices we decided on are not all that complicated, and it seems like it was a lack of this type of information in earlier design documents and discussions that made it seem urgent at this point. Going forward will be easier with these standards in place.
