Continuous Integration

Continuous integration (CI) is a development approach using software that monitors your version control system and initiates an automated build after any change to your project. Once the build is complete, all automated tests are run and notifications are triggered.

CI also implies the workflow of constant integration to the version control trunk. That is, there are no long-running branches that will need to be merged at some point. Check-ins are done to the development trunk to facilitate Continuous Delivery/Deployment (CI/CD).

Pain Points

  • Team-wide integrations are difficult, and nearly impossible to do quickly
  • “We’ll integrate just before we ship”
  • “It worked on my machine…”
  • Every morning, the team wastes time fixing the nightly build
  • The same few people always break the builds, and others clean up behind them
  • Mysterious faults frequently creep into the product
  • Developers resist updating their local code base because they don’t want to deal with the inevitable problems they’ll encounter


  • The code is continuously integrated so any regression or new bugs are visible, as well as progress, and the code is always in a known state
  • Compilation issues are attributed to the developer who checked in the non-working code, enabling them to learn from their own mistakes
  • When combined with a solid test suite, the functional state of the product is always known
  • Problems are detected almost as quickly as they occur
  • The team becomes accustomed to having a working system and becomes intolerant of “Broken Windows” (see Software Entropy in The Pragmatic Programmer (Thomas & Hunt, 2020))


  • The team is practicing Continuous Integration, and all of the following are true: (Major Boost)
    1. Every developer commits at least daily (hourly is better) to the shared mainline branch
    2. Every commit triggers an automated build and all unit tests are run
    3. If build and/or test fails, the build is repaired within ten minutes
  • The team does not consistently check in daily/multiple times per day (Significant Setback)
  • The team is not practicing Continuous Integration (cannot answer ‘yes’ to the three questions above) (Significant Setback)
  • You have no automated unit tests (Significant Setback)
  • The “CI” build does not run continuously (Significant Setback)
  • There are long-running feature branches (Disaster). Consider the use of Feature Switches instead


✓ Critical ❑ Helpful ❑ Experimental

Adoption Experiment

Steps to first adopt this habit:


  1. Create a scripted build for your product.
  2. Set up a clean environment and install your build tools and a version control client, or use the native pipeline facilities from your hosted VC provider
  3. Discuss with your team. Ask them to agree that all breaking builds will be repaired or backed out within ten minutes during this development time-box


  1. Add your product to the continuous integration system
  2. Enable email notifications
  3. Intentionally break the build to verify the system
  4. Add a basic unit test to the system

Evaluate Feedback

  1. Discuss the usefulness with the team
  2. How often did the build break?
  3. How long did it take to fix an average problem?
  4. How has the team’s work habit changed?

What Does it Look like?

The build machine, usually running in the cloud, runs constantly, 24x7x365, looking for changes in version control and then building the latest, most authoritative version of your product. QA, testers, managers, and the users you are working with can always access the latest build for casual evaluation.

A developer commits their code no later than the usual build time before they plan to go home, then they wait for the continuous integration to complete, and notify them that the build is good. Then they go home for the day. Or, if the build was bad, they jump back in and get things fixed. But they don’t go home and leave a broken build for someone else to fix.

Jenkins1 is a popular continuous integration system. It has a vibrant plugin ecosystem that integrates with most existing systems and tools. It’s written in Java, but plays well with multiple technologies. It’s also a well-vetted open-source tool, so the price fits every budget. VC hosting providers such as or provide cloud-based pipeline build environments at both free and paid tiers.

Martin Fowler’s blog (Fowler, 2017) suggests the following test to evaluate whether you’re really doing Continuous Integration correctly:

  1. Every developer commits at least daily to the shared mainline branch
  2. Every commit triggers an automated build and test
  3. If build and test fails, it’s repaired within ten minutes

It sounds simple, and it is, yet the vast majority of teams who think they’re doing CI can’t pass this test. According to some surveys2, 90% of survey participants who said they were practicing CI did not integrate to the mainline daily (#1 above).

Warning Signs

  • Your team only commits code every other week (or even every few days)
  • You have no automated unit tests
  • You have automated tests, but you disable them (so they won’t break the builds)
  • You disable your CI builds until the end of the iteration
  • You schedule your “continuous” builds to run once a day. Or once a week.

Growth Path

Once the build is in place, try to improve the state of the build with each commit. For instance, add a code coverage tool to expose how much of the product is exercised (or missed) by the unit tests. Focus on increasing that number with every code commit.

Remember, it’s okay to break the build, but it’s not okay to leave it broken. The only team member who never breaks the build is the one who isn’t writing code.

How To Fail Spectacularly

  • Committing code and going home before seeing the result of the CI build.
  • Committing code and going on vacation before seeing the result of the CI build. (Sadly, this is a real example)
  • Disabling the tests because “they always break and that slows down the team” (Again, an actual quote).
  • Turning off the CI system entirely because developers frequently break the build. Bonus demerits if you continue to brag about having a CI system while it’s turned off.
  • Providing an annual bonus pool and deduct money from it every time a build is broken. The manager involved didn’t understand why developers stopped sharing their code frequently.
  • Writing your own continuous integration software. There are too many excellent products available already. If you think it’s trivial, then you don’t understand the system yet.

  ←Prev (Version Control)(StorySlicing.txt) Next→

Follow @growsmethod in the Fediverse, or subscribe to our mailing list:

Sign up for more information on how you can participate and use the GROWS Method®. We will not use your email for any other purpose.