Continuous integration is software that monitors your version control system and initiates an automated build after any change to your project. Once the build is complete, any available automated tests are run and notifications are triggered.
- Teamwide integrations are difficult, and nearly impossible to do quickly
- We’ll integrate just before we ship
- It worked for me…
- Fixing the nightly build is done every morning
- The same few people always break the builds, and others clean up behind them
- Mysterious breaks frequently creep into the product
- Developers resist updating their local codebase because they don’t want to deal with the inevitable breaks they’ll encounter
- The code is continuously integrated (duh!), so breaks 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 from The Pragmatic Programmer)
✓ Critical ❑ Helpful ❑ Experimental
Steps to first adopt this practice:
- Create a scripted build for your product. Many IDEs will generate this for you.
- Set up a clean environment and install your build tools and a version control client
- Discuss with your team. Ask them to agree that all breaks will be fixed in under an hour for the next iteration
- Add your product to the continuous integration system
- Enable email notifications
- Intentionally break the build to verify the system
- Add a basic unit test to the system
- Discuss the usefulness with the team
- How often did the build break?
- How long did it take to fix an average problem?
- How has the team’s work habit changed?
What Does it Look like?
The build machine 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 30 minutes 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 far and away the most popular continuous integration system. It has a vibrant plugin ecosystem that integrate 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.
Martin Fowler and Jez Humble suggest the following test to evaluate whether you’re really doing Continuous Integration correctly:
- Every developer commits at least daily to the shared mainline branch
- Every commit triggers an automated build and test
- 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 one study, 90% of survey participants who said they were practicing CI did not integrate to the mainline daily (#1 above).
- 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.
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 by at least 0.001% 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. (Yes, this is a real example!)
- Disabling the tests because “they always break and that slows down the team”.
- Turning off the CI system because developers frequently break the build and it slows them down to keep compiling. 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)(Timebox) Next→