When a third party is implementing your application idea, it may seem like the developers are hidden behind closed doors and the code is churned through a meat grinder. When you get the finished product, the result is something that resembles meat, but you’re not quite sure. With software development becoming more and more prevalent in society recently, there are many options to get your application made. The enticing option is quick and cheap implementation. However, this approach often ends up being buggy or simply non-functioning which results in many wasted hours down the road. Ideally, the resulting software should meet the customer needs and be properly functioning. What is the best way to do that? Quality assurance. Whether you’re a customer or developer, let’s look into what should happen in the ‘meat grinder’ to produce ideal software.
Source Control
To begin, all code should be managed via source control and stored on a secure server. Source control is essentially code control. It allows developers to manage and track any changes that occur during the development process as well as who made the changes. We recommend the industry-leading standard in source control known as Git. With Git, developers are able to separate different software features that multiple developers are working on, then later merge those into one final version of the code.
A typical workflow goes like this:
- A developer is tasked with creating a new feature.
- The developer creates a new ‘branch’ from the main codebase. Using a branch ensures they are working in an isolated environment and the code will not conflict will other work going on at the same time.
- If applicable, unit tests are developed to test the new code.
- When development of the feature is completed, a request is made to merge the new code with the main codebase. This is the step where the code is reconciled with other’s work (similar to ArcGIS versioning).
- First, the code is built on _a_ ‘continuous integration’ server. This will run all unit tests on the new code to ensure it doesn’t break anything done previously.
- Second, the code review process begins. Reviews are done in two parts: A developer ensures the code complies with established coding standards. A second developer or project engineer ensure the code meets the requirements from the client.
- If the code does not meet the standards or satisfy the requirements, that feedback will be given to the original developer.
- The developer will make the necessary changes and submit the code for review again.
- Once the tests have passed and the reviewers have given approval, the code is merged with the main codebase.
- We’re not done yet. When all features for a release have been built and reviewed in the process above, another request is made to review all of the combined features.
- The team will review the code as a whole and step through all test cases before that version of the code is made final.
This process should occur before a delivery is made and the software is implemented in a test environment. At that point, user acceptance testing takes place, giving the software another pass through testing.
The end goal is to deliver code that works well and executes the critical process that’s it is intended to do. In food terms, the final result looks less like a hunk of mystery meat and more like a Filet Mignon served at Elway’s. I think it is time for dinner. All this food talk is making me hungry…
What do you think?