Continuous integration is a philosophy used by teams of software engineers working collaboratively. The idea behind this philosophy is to integrate code produced by the team’s engineers on a more frequent basis. Instead of engineers merging their code into the master branch at the end of the week, this is instead done on a daily basis. Some teams may even commit several times per day.
Automated testing sits at the basis of most continuous integration workflows, making it a viable dev strategy, with continuous integration tools running tests on all commits to the project. This mitigates the chance of error and reduces the need for manual testing. Would the benefits of continuous integration outweigh the overheads of increased manual testing? With automated testing, we don’t need to have that debate.
In this article, we outline some of the benefits a continuous integration workflow offers to development teams.
Faster Development
The idea that continuous integration will quicken development may seem counter intuitive. Breaking features up into smaller bundles of code and making more commits? How would doing something more often make things faster? Wouldn’t the overheads of making these commits would actually lead to a longer development process?
This is why automated testing is so crucial to continuous integration. The automated testing provided by continuous integration tools mitigates the time overheads. Of course, automated testing would also reduce time in a traditional integration model. The real time saving potential of continuous integration is in debugging. Automated testing’s purpose is to minimize a potential drawback of the philosophy.
Easier Debugging
Which would you rather debug? A file with 300 lines of code or a file with 3000 line of code?
With continuous integration, debugging can be isolated to the commit uploaded on the Thursday morning by Dave. Traditional integration would require debugging of the combined work of the entire team over the whole week. Dave just has to find the error in the 300 lines of code that he committed. In traditional integration the whole team would be trawling through 3000 lines of code.
Immediate feedback
With the continuous integration model, we can easily identify who was responsible for the bug: Dave.
Fortunately, Dave doesn’t need to incur the wrath of his teammates after they spend hours tracking down his error. This is because the automated testing will most likely discover his error immediately and send his commit back to him to rectify. Automated testing can’t catch everything, but a robust system of testing will save a huge amount of grief later on.
Receiving feedback on your work in shorter intervals also means that the code is top of mind for the developer that created it. Remember that function you weren’t too sure about it when you wrote it? That will be the first place you check when your code fails the automated testing in a continuous integration system. You only wrote it an hour ago. At the end of the week you’ve probably forgotten all about it and naturally assume someone else made an error.
Less Chance of the Master Branch Changing
Making more frequent commits reduce the chances that the master branch will change significantly while you work. If you commit twice per day, the version of the source code you are working with is only going to be a maximum of four or five hours old. If you commit at the end of the week, the code you are working with on Friday could be four or five days old.
Over the course of the week a team of developers could be pulling that code in all different directions, increasing the chances of a merge conflict. If you commit more frequently, you’ll have a more up-to-date version of the code to work with. In addition, your fellow developers will have a more up-to-date version of your code to work with as well.
Exponential Bugs
Sometimes finding and correcting a problem does nothing more than unmask another issue. There’s not many things worse than your solution to a problem revealing a bigger issue.
Testing for bugs more frequently in a continuous integration model reduces the chances of layering bugs on top of bugs.
Redundant Code
If one developer starts taking the project in the wrong direction, they could waste a week of development time doing so. With that week will come layers of redundant code. With a continuous integration model, up-to-date versions of their work will be in the hands of other developers on a more frequent basis. Rather than wasting a week going in the wrong direction, the developer could be advised of their mistake early on Monday afternoon.
The continuous integration methodology offers many benefits that can help developers identify problems early and spend less time debugging. Less time debugging means more time building features. Better features mean better products.