How Continuous Integration Helps Your Product Win
“All I Do is Win Win Win, No Matter What What What” – DJ Khaled
At some point in a meeting with your developers, you’ll probably hear them talking about Continuous Integration, or CI. It’ll sound something like “We really need a CI server for our builds. We need to set up our project on Travis or CircleCI.” The details of what continuous integration is, from a technical perspective, are covered in depth by Martin Fowler (one of the gods of programming).
Our focus for this article is on helping you understand the business impact of using (or not using) continuous integration.
What Is Continuous Integration? (Abridged Version)
We define continuous integration as the process of using automated tools to ensure that changes made by developers do not degrade the overall quality of the application.
It combines the use of best practices in source code management alongside testing and build automation to continuously assess the health of new work performed on the project.
How CI Works In Real Life
For purposes of our example, I’ll be sharing screenshots and real CI reports from one of my open source projects hosted on Github and a continuous integration service called TravisCI.
Here’s a screenshot from my project in TravisCI:
As you can see from the above list, I made four commits to the project. On the first commit, I did something wrong. Then, in my second commit, I fixed it.
What’s great about this is that Travis is running a “build” every time anyone checks code into my project. So, as soon as someone does something that breaks the build, everyone on the team knows it. Travis can send email notifications, post a note to Slack, or just about any other notification method you can think of.
Here’s an example of the email Travis sent me when I checked in the bad code:
And when it was fixed:
Here’s what Travis actually did when I checked in my code:
How excellent is that? Within a minute or so of me checking in my code, the project has been validated as still being in working condition by a 3rd party tool.
Your team can have a lot of fun with someone who breaks the build. On one team I worked on, we all had Nerf guns and would turn around and blast the developer who had checked in the nefarious code. However, a broken build should be fixed immediately because the problems can cascade quickly if you don’t get it fixed.
Why CI Matters to Your Business
If your product is at the core of your business, continuous integration practices should be mandatory. Here’s why:
- It encourages smaller units of work and more frequent integration of new code, which is one of the fundamental building blocks of stable systems. Stable systems have less churn and happier users.
- A stable build and development environment allows new team members to come online and immediately become productive without fear of breaking the application unknowingly. The faster you onboard new developers, the faster your product moves.
- Near-immediate feedback on new code exposes problems with either the process or with individual team members. By constantly assessing the quality of new code, the chance of a bad checkin bringing the team to a halt is significantly reduced, saving you money and frustration.
Just Remember
- Continuous integration is the fundamental component of any stable, fast-moving development team
- Continuous integrations costs a small amount of time up front, but saves massive amounts of time over the life of your project
- Continuous integration helps new team members become productive immediately by minimizing the impact of breaking changes
Your Assignment
- Meet with your development team and get the current state of CI for your project. If you don’t have CI, immediately get it prioritized on your roadmap.
- Once you have CI in place, get onto distribution list for all continuous integration reports.
- Follow the progress of your project closely for the next few weeks. Note patterns of who checks in breaking changes. Discuss concerns with your team.