So, your technical lead just asked you to adopt continuous integration and you’re looking to know what continuous integration is and what its benefits are. Trust me, many people struggle with quantifying the benefits of continuous integration. In fact, one big dilemma people face before attempting continuous integration is determining if the effort is worth […]
So, your technical lead just asked you to adopt continuous integration and you’re looking to know what continuous integration is and what its benefits are. Trust me, many people struggle with quantifying the benefits of continuous integration. In fact, one big dilemma people face before attempting continuous integration is determining if the effort is worth the benefit. And this is exactly why I’ve decided to address continuous integration (CI) as the subject in today’s post.
Let’s imagine that you are one of three developers who are working on a project. The two other developers are Scott and Susan. Also, I’m assuming your team is using a source control management (SCM) tool, such as Subversion, Team Foundation Server, or Git. We’ll start the project off with the SCM full of the ideal code from a previously ideal software project.
On Monday, day one of the project, you are the first person to pull down the code from the SCM repository. Later that morning, Scott pulls down the code and starts to enhance one part of the system’s code. Later that same day, Susan pulls down the code and starts to fix a bug in an entirely different part of the system. Susan makes quick work of the bug fix and checks in and commits her change back to the SCM repository. Meanwhile, Scott plugs away at his enhancement, which he checks in and commits just before he leaves on Friday afternoon.
Since you have to do a demo on the following Monday morning, you want to get the latest code and review the enhancement and the bug fix. And so, late Friday afternoon, you pull down the latest code from the SCM repository. Very quickly you figure out that things have gone very wrong. You can’t build the project.
It just so happens that people are not good at connecting things that are separated by either distance or time. In this example, Scott was separated from Susan because they worked on different parts of the system. Also, over the course of the week, the implementation details became separated by time. The implications of this are that Scott and Susan can both do careful, thorough work and you still could get a broken build.
For example, let’s say that Susan’s fix changes a part of the system that Scott depends on, but he’s not modifying it. Scott’s code is relying on the behavior to work the way it is working, but unbeknownst to him, Susan is changing it.
The way to solve this problem is to connect these two developers’ work, which is disconnected by space and time. This is the role and benefit of CI.
The first stage of CI is to bring all the files down from the SCM repository to an empty folder and rebuild all the system’s components. The reason CI starts with an empty folder is to catch when a file is missing or removed from SCM. The process of rebuilding all the system’s components ensures that the code that’s in the SCM repository is complete and correct.
There are two prerequisites for this stage. First, this CI stage needs to be triggered when a code change is committed to the SCM repository. Second, the rebuilding of all the system’s components needs to be automated with an approach such as a build script.
Once in place, the Rebuilding stage will uncover missing files, build conflicts, or compilation errors very quickly.
The second stage of CI runs all the automated unit tests for all the system’s components. The reason CI runs these tests is to ensure that the code that was just rebuilt is all working as the developers had intended it to work. If the code is not working as intended then one or more unit tests will fail.
The prerequisite for this stage is that the developers have written automated unit tests. Quantifying the value of unit testing is a bigger topic than this blog post, and so, we will come back to that on a later date.
The third stage of CI involves running one or more automated analysis tools. Tools like these can report errors and metrics that indicate a drop in security, maintainability, or quality. Other tools can also enforce coding standards, guidelines, and standards.
The primary benefits of CI come from problem prevention, early detection, and quick resolutions. These are all good, but show me the money.
CI works in the background. It helps one developer avoid retrieving code from the SCM repository if there are build or instability issues. This keeps developers from wasting their time with problems caused by another developer. Also, any issue found through CI is discovered before the QA team discovers it. That saves QA the time of writing the issue, tracking the issue, and verifying that the issue is resolved. Since time is money, CI can bring real cost savings. Because development environments vary so much it is hard to know exactly how much time will be saved, but I expect that the team’s time savings will quickly surpass the initial time invested.
What are your thoughts and experiences with continuous integration?
Source: Stephen Ritchie, Pro .NET Best Practices (New York: Apress, 2011). Excerpted in part with permission of the author.
Agile coaching is what we love to do. There is nothing better than seeing a...
Agile experts think great product owners act as entrepreneurs for their product. Product owners and...