You have a continuous integration (CI) tool or server. Your dev teams check in regularly. Your CI server tests your checked-in code and tells you whether it passed or not. Maybe you’re even on your way to continuous delivery (CD) and continuous deployment by deploying more than once a quarter.
And I bet if I asked you, “Do you practice CI?” you’d say, “Yes, we do." But you may not be doing it as well as you think you are. Many teams are missing key aspects of CI.
It’s easy for me to assume that you follow the practices I just described, since they are common in modern software development teams. And it's easy to guess that you or your teams are not checking into your master (you might call it "trunk" or "mainline") on a daily basis.
Am I right? If I am, then I am afraid to tell you that you are not doing CI. You’re missing out on key benefits of CI continuous integration, and you might not be as ready for CD or continuous deployment as you think you are.
Here’s why you probably don’t do CI as well as you think you do.
What is good CI?
On the surface, CI involves software developers integrating their changes in a source repository, building the combined software, and testing that it works. Generally, they use a CI server or hosted CI tool to do this, and the process requires self-testing code. CI is a feedback loop that helps teams get better and verify their code.
What the CI process looks like.
You are probably doing something that looks just like the above diagram. But that image of the CI process probably does not include two fundamental principles required to truly do CI. My favorite definition of CI comes from Jez Humble:
"CI developers integrate all their work into trunk (also known as mainline or master) on a regular basis (at least daily)."
Humble specifies two fundamental principles of CI. The first is “integrate all their work into trunk,” and the second is “at least daily.” Integrating with trunk, mainline, or master daily is part of the definition of CI. Without it, you are not practicing true CI.
What most people are doing when they say, "Yes, we do CI"
Through research conducted at ThoughtWorks, we identified different patterns of CI practice. Most often, these patterns of behavior looked like CI as demonstrated in the illustration above, but they didn't follow one or both of the key fundamentals described in Humble's definition of CI.
Here are two of the most common CI anti-patterns.
The CI tool pattern
The most common pattern starts with CI tools. In response to the question, “Are you practicing CI?” the teams we observed to follow this pattern said, “Yes, we have a CI server,” or, “Yes, we use x CI tool.” In fact, this pattern is so common that in our study, only 10% of participants acknowledged that having a CI server was not the same as practicing CI. Conversely, 90% of teams that used a CI tool said they were practicing CI regardless of whether they were specifically practicing the fundamentals of CI or not.
The long-lived branch pattern
An equally common pattern was to use long-lived branches and to not regularly check into master. There are two common forms of this pattern. In the first, teams checked into branches often but ran CI only on the master branch with infrequent, less-than-daily merges to the master branch.
In the second, teams ran CI against their branches regularly but without frequently integrating those branches back to the master branch. Although they were running through the process shown in the diagram above, because they ran CI against feature branches rather than the master on a regular basis, they were in fact practicing continuous isolation rather than continuous integration.
Other CI anti-patterns include feeling pain when merging branches due to merge conflicts or mental fatigue, running a CI build with poor test coverage, or allowing the build to stay red for long periods. In all of these cases, CI is not being practiced at a fundamental level. If you follow these patterns, you’re not doing CI as well as you think you are.
Why good CI is important
There are good reasons why CI is defined the way it is and real benefits to doing it as defined. Unless you practice CI correctly, you are missing out on its key values. Review the benefits of CI below and decide for yourself if you’d add value by doing CI as I've defined it.
Avoid merge conflicts
If you integrate to master frequency, there are fewer code conflicts between your changes and those of others. If you don’t, then the chances of a conflict increase. Unfortunately, teams ignore this merge-conflict pain when they think they are already practicing CI. Sometimes they ignore the pain because someone else has to merge their pull requests. And sometimes they ignore the pain because it’s not as bad as it used to be when they merged all code changes at the end of a project. But if merging and integrating take hours to resolve, then you’re not doing CI.
Collaboration and co-ownership
When your team checks into master on a daily basis, there are no code silos; everyone can see and integrate with the code of others. Everyone owns the health of the build and the status of the product. The whole team can move faster and work more effectively together when changes are not private or restricted to certain team members.
Fast feedback and reducing risks
By making small changes to the master frequently, you get faster feedback about those changes from the rest of your team and the business. This is a key driver for CI, but also for agile and continuous delivery.
CI facilitates CD
In a world where DevOps culture is hot and people want to release frequently, the benefits of good CI continue to grow. With CI as I defined it, you always have the most recent changes ready to deliver. With good CI, you have many smaller changes to your code base and so are more able to make many small changes to production.
How to do CI as well as you can
If you want to move quickly, be faster, disrupt, innovate, do CD, and have a DevOps culture, then you must embrace true CI. Just having a CI server or checking into branches once a day is a good starting point. But understanding the value of CI and getting back to the fundamentals will up your CI game and bring more value to your organization.
Here are some ways you can start to change your CI practice for the better.
Check into the master regularly
Get back to the basics of CI by continuously integrating. Even if you are “doing CI,” you can always do more to improve. My advice is to commit code to your repos and integrate branches to master more often. Aim for checking in and merging to master at least once a day, but don’t stop there.
Do trunk-based development
This is controversial, since many people love GitHub flow, but branch-based workflows do not facilitate the best CI practices. The State of DevOps report 2017 confirms that high IT performers have the shortest integration times and branch lifetimes, with branch life and integration typically lasting for hours.
As an example of this, Dan McKinley reported that branching in code (using feature toggles), rather than branching in version control, was one of the key practices that enabled Etsy to deploy more often. If you want to do the best CI, work on master. If you can’t work on master, keep your branches to a minimum and merge them many times a day.
Use automation
Automation is a cornerstone of strong CI, so if you haven’t automated anything yet, now is the time to start. And if you have automated, ask yourself, “Why can’t this be automated?” every time anyone on the team does anything manually more than once. If it doesn't help you do CI better, it will definitely help you do CD better.
Be a real CI practitioner
Many development teams do not know the true definition of CI, and many confuse practicing CI with simply using a CI tool. As a result of this confusion, many CI adopters fail to practice the key fundamentals of CI and therefore fail to experience the true benefits of CI. If you want to make the most of CI on your teams, check in (or merge your branch) to master at least once today.
Do you do CI as well as you think you do? Let me know in the comments below.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
