When it comes to software and web development, the conventional wisdom usually goes like this. Each team, or each member depending on the size and complexity of the software in question, work on their codes and continually test their own codes until whatever feature they were supposed to be working on actually works and submit their codes to their manager. Once every member have submitted their codes, all of them gets integrated and run for a final test, where there’s probably at least a 50% chance that that particular software is going to break. Why? That’s because integration error is the bane for any software and web developers.
The problem with that development practice is that it neglects to account for the other codes and features that makes up the entirety of the codebase. In software development, this is perfectly fine as having several standalone teams taking full responsibility of their own codes is much more preferable than having one single large team responsible for the entire codebase. In fact, the micro frontends approach to web development is built on this very same principle. The problem lies in the possibility that those codes might not play well with each other, leading to errors and faults occurring during integration. One of the more novel ways of avoiding this is with the practice of what is called continuous integration.
Great things are done by a series of small things brought together.
Continuous integration (CI) is exactly what it says in the title, it is basically a development process in which the integration process perpetually happens every time small alterations and/or additions are made to the codebase. ThoughtWorks’ Martin Fowler defines the process as “a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly”. As you might’ve guessed, this development process brings with it several benefits compared to the standard development process, such as:
- Less debugging and troubleshooting.
Instead of implementing changes thousands of lines of code at the same time, CI breaks that down into much smaller steps, with only several lines of code changes and additions being integrated at a time but performed several times during the day. The benefit is two-fold, you have less risk of encountering any errors and when you do run into one, finding out what went wrong is much easier as you don’t have to perform the sisyphean task of checking over several thousands of lines of code.
- It’s integrated in an agnostic environment
Software development can be somewhat esoteric. There are weird instances in which a code may work just fine in one environment but fail once it’s moved to a different one. With a centralized CI server, tests and integration can be run in an environment mimicking a real world setting so that when your boss tells you that your code doesn’t work when he tested it, you can confidently tell them that the problem is on their end and not on your code.
- Reduce conflict between teams and/or members
In the standard development practice, the first thing that always happens whenever integration errors occur is mudslinging. If their code runs well in isolation, it’s not like anyone is going to voluntarily sacrifice themselves to the altar which would eventually result in mudslinging, only passive-aggressively. I’ve actually seen this happens once so using a completely unbiased third party like a CI server for independent review could keep this internal conflict from happening.
- Keeps the sanctity of your code
The CI server will only merge the changes and additions into the existing codebase if, and only if said changes pass the prerequisite tests. There is absolutely nothing worse than deploying a set of broken codes and having to rollback updates because of that. Take a look at this case with the video game Sea of Thieves. They took down the server for the game to implement an update for the game, and after several hours of players reporting problems with the update, they took down the server again for an emergency maintenance. That still didn’t fix things and they took down the server again for the third time in 24 hours for another maintenance and even then, the game is still apparently suffering from certain issues.
It used to be that updates are implemented rather infrequently, but if you’ve ever paid any attention to how often a mobile app gets updated in the past few years the you should’ve noticed already how often small updates and bugfixes are deployed. The same thing applies to websites. Now that static websites are nearing the point of extinction, web apps with varying levels of interactivity is the norm. Even browser games are now massively popular, with hits like Agar.io, Slither.io, 2048 etc beginning their life as a web app before being launched as a native mobile app. While major updates to a web app is still relatively infrequent, perpetual improvements are always happening in the background, making practices like continuous integration a necessity for web developers around the world.