Software development is a complicated and detail-oriented process. It requires hours of focus daily. The profession also requires near inhuman levels of patience as you spend most of your time with broken systems. Developers who build those systems are a special breed. Creating software is more challenging when you add deadline pressure and the collaboration of numerous creative people. This week, I want to discuss another obstacle to software delivery: the use of source control to create versions.
Software is in a constant state of construction and revision. Each day code is revised, and developers create a shorthand for what they are working on to keep track of these changes. Software developers call this shorthand version. Microsoft uses the following terminology for versioning software: major, minor, hotfix, and build number. A major number represents a significant improvement in the look or performance of the software; thus, version fifteen is superior to version fourteen. A minor modification is a minor version number. For instance, a new software version allows for alphabetically sorting columns, becoming version 15.2, which is superior to version 15.1, which did not have that feature. Version 15.2.1 is superior to version 15.2.0 because it addresses errors created by German or Russian characters. When we talk about hotfixes, a development team often deals with defects. The final number is the build number, usually a date stamp of code compilation. Version 15.2.1.20220925 is a day older than version 15.2.1.20220924. By glancing at this numbering system, a software developer, product person, or executive knows which version is in any development environment. It is an elegant and transparent way to understand the progress of a software development project.
Unfortunately, the business world is not elegant or organized. A version can exist in production, and a different version will live in the User Application Testing environment. In situations like this, most source control tools can branch code, so the main version of software exists in the trunk, and a version can live in a different branch. It is supposed to segregate code into two lines, which developers merge once the software is released. The ugly truth is that software is being manipulated in source control by hundreds of people creating branches and combining them. This situation is filled with entropy as developers are making fixes to one component and ignoring the other. In cases like this, code in one branch can exist, and code that creates critical errors might exist in the other. The team will not know until the code is merged into source control or pushed to a testing environment. Merge conflicts like this are expensive to fix and often happen publicly, hurting your credibility with customers.
As a result of vague promises made to the business, product managers insist that the updated code find a home in the previous version. It is called backporting, and it metaphorically resembles placing a rocket engine on a bicycle and expecting it to behave like a spaceship. When a development project requires backporting, it introduces further fragility and technical debt, which shows up in expensive ways. Instead of source control adding focus to a project, it creates more entropy.
There is a proven way to fight this problem. It focuses on developers keeping their code repositories up to date, and the business focuses on the next release instead of prior ones. If something needs to go to production, the team promotes code, knowing that the company is not introducing technical debt. It is a practice known as “trunk-based development.” If you are using trunk-based development, you are forbidden to create branches. The developers on the project check in and check out of the same branch, known as the trunk, guiding development. At any point, the most recent version of the software is in the trunk, and the need to perform mergers becomes unnecessary. Backporting to the previous version stops because the most recent version is the only one.
Source control is a powerful tool, but so it s a chain saw. You can use it to cut firewood or create sculptures. It is also possible to maim and kill others with it. The difference is training and intent. So if you use source control in your project, use a trunk-based approach. You will be glad you did.
Until next time.
No comments:
Post a Comment