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

Benefits

• 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))

Assessment

Application

✓ Critical ❑ Helpful ❑ Experimental

Adoption Experiment

Steps to first adopt this habit:

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.

Jenkins¹

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 gitlab.com or github.com 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 surveys²

, 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→

---

Find Out More...

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.