3 mistakes most people make with Continuous Integration (and how to avoid them)
3 mistakes most people make with Continuous Integration (and how to avoid them)
How do you really achieve Continuous Integration?
There are 3 mistakes most people make when trying to do Continuous Integration:
Mistake #1: Confusion of Continuous Integration with the use of a CI server
It is definitely not enough to use a CI server. Continuous integration is a practice, not a tool. A CI server like Jenkins is just a tool. But the idea of CI is mainly about software development practices.
And yes, we can use a Continuous Integration (CI) server to make it easier to implement practices.
Tools are useful, but the result depends on the practices you implement.
Mistake #2: When a build breaks, it doesn’t get fixed right away
If a build is broken, something is wrong with the build and integration of the software.
This can be a failed test. This can be a dependency that was not taken into account.
Thus the software is in a kind of undefined state.
As long as the build does not work properly again, you can neither release the software with confidence nor develop it further, because there is obviously a problem.
Simply continuing to work can lead to introducing additional bugs that you don’t catch. This makes the whole system even more unstable and even more difficult to repair.
Mistake #3: Not having enough confidence to release the latest build
Lack of confidence despite a successful build, means that you are not sure that the software works the way it was just built.
This may be due to missing or incomplete tests. It may be because you still have to rework manually before you can go into production.
Or because features are not fully implemented (hint: you could use feature flags to avoid this).
But that is exactly the goal of CI:
You want to have a statement about the quality of the software you are developing at any time, so that you can deliver the software to your customers without worries.
What should you focus on?
The core idea of CI is to make releases a business decision, not a technical decision.
The team keeps their latest code ready to release.
Continuous integration is about being able to release your team’s latest work whenever you see fit.
And this is only possible if you consider 3 things:
Merging together all the code the team has written as often as possible into the integration branch.
Never break the integration build. Automate it, have good tests and make sure you know the build is in a good state.
Keep the integration branch build ready to release anytime. A release should be a nonevent.