Version control — the process of tracking and managing changes to code, applications and supporting infrastructure — is a core part of the development process.
You can’t have an effective application lifecycle management process without a way to track and trace changes. And yet, it’s surprising how often teams don’t have a mature version control process in place.
Where that’s the case, developers waste huge amounts of time and money trying to keep track of everything and fix issues when applications break.
That’s why it’s the very first thing we analyze in our ALM assessment.
In this article, we’ll look at the importance of having a mature version control process, what that process should look like and how we at Kingsmen Software assess version control as part of our technical due diligence report.
Why Do Organizations Need a Mature Version Control System?
Version control is a vital part of the software development process for several reasons. First, you want to have full traceability from requirements received from stakeholders through to code in production, says Bill Clerici, CEO and Partner at Kingsmen Software.
When you have full traceability into every change that was made, it’s simple to rectify any issues that arise. You can trace an issue back to the exact line of code, and then trace that back to the requirement. Developers don’t waste time second-guessing what went wrong or why the change was made.
The fix might not be simple, but finding what went wrong can be.
Sara A. Metwalli, a Qiskit developer at IBM, describes three key benefits that strong version control offers:
- It creates backups. Whenever a user clones a repository, they create a backup of the current code version. This provides better protection in the event of a server failure.
- It makes experimentation easier. Development teams can run multiple versions of a code base simultaneously to save time when creating and testing new features.
- It facilitates better collaboration. Version control means developers can contribute to projects wherever they are based.
Building software without a version control process is a high-risk strategy, akin to not having backups, writes Kudzanayi Dzvairo, a software engineer at RubiconMD. “Version control protects source code from both deliberate and unintentional mistakes,” Dzvairo writes. It also allows developers to move faster and more efficiently, especially at scale.
The Processes, People and Tools of Excellent Version Control
You can measure the maturity of a team’s version control by looking at the processes, people and tools involved in the system. Here’s what we would expect to see:
A development team’s version control processes should cover how they track and manage changes in everything, from code and databases to infrastructure and continuous integration workflows.
There should be a clear process for making changes, uploading new code and tracking everything. Developers should “commit early and commit often,” says Lance Harvie, founder and CEO at RunTime. “This will help you make your commits small and limited only to related changes. Make small changes but do not commit unfinished work to avoid breaking the build.”
At the same time, developers should document everything by writing a commit message that provides a short description of the changes. “The summary should provide details on the intent and purpose of the changes and how it differs from the previous implementation,” Harvie writes. “Link code changes to work items for the changes’ traceability.”
Developers can maintain consistency by “bundling associated files together in a commit,” says Don Hall, an IT operations manager at the United States Department of Defense. But unrelated changes shouldn’t be bundled together, as this can make it difficult to identify errors. “It can also create challenges for situations where source code needs to be reverted without also reverting unrelated changes that were included in the same commit.” New code should be thoroughly tested before it’s committed, he adds.
There should also be a continuous integration process. This is the “practice of integrating feature branches into the main branch of code to be built and tested automatically,” explains Marat Levit, an associate partner at Servian.
Developers can use a Git repository to automatically compile, execute and test changes. If there is ever a failure, automatic warnings can alert developers, who will then roll back changes or release a fix.
“Implementing continuous integration allows teams to fail fast and fail often,” Levit writes.
The people involved in a company’s version control system should have clearly defined roles, especially given the impact version control has on collaboration.
Version control avoids many of the collaboration issues that can occur when you have multiple teams or developers working on the same code, says web developer Justin Kampert. You can avoid conflicts by having individuals responsible for specific branches or issues.
“That lead can then review the propositions and resolve any conflicting issues or combine any necessary changes that have been submitted,” Kampert writes.
The primary tool used in version control is a version control system (VCS), which acts as a repository for every version of your code.
A VCS allows you to make multiple changes and then commit those as a single group. This lets developers get work out in batches. And if any of that work needs to roll back, you will have the full change history so you can trace what happened, spot bugs and restore features that may have been removed.
Developers don’t have to use a third-party VCS. Many create their own, whether for privacy reasons “or simply out of a desire to hack everything themselves,” says Tammy Xu, a reporter at MIT Technology Review.
Assessing Version Control
Version control is the first discipline we analyze in our application lifecycle management assessment. As part of our thorough report, we analyze the processes, people and tools as described above in the following areas:
- Application code versioning, or creating unique states of an application for each update.
- Database versioning, which refers to the recording, sharing and tracking of all versions of a database.
- Configuration versioning, or deploying different configurations of the same code.
- Branching methodology, the strategy development teams use when writing and merging code using version control.
- Infrastructure configuration versioning, or creating traceability in the infrastructure development teams use to run applications.
- CI workflow configuration versioning, which refers to the automated systems developers use to build, compile and test code.
We grade each of these areas from poor to good on a heatmap that shows investors, at a glance, what areas of version control they should be concerned about.