CircleCI, Jenkins, TravisCI (recently acquired), GitLab CI. You know how they work, I believe.
If you want to do Continuous Integration, almost all of us are doing it wrong. (Of course, it doesn’t depend on the tool, but on the people using it…)
I am guilty of it myself. My clients usually use Git as a version control system. Some of them follow a git-flow model. Others use GitHub-flow or just simple feature-branch models. None of this works with true continuous integration.
Between 1999 and 2001 Continuous Integration was “born”. Kent Beck and Ron Jeffries invented and codified it while working at Chrysler Corporation. The school of Extreme Programming (started by both of them) was the first to explain what CI is supposed to mean. In a nutshell:
CI means integrating all developers’ changes into mainline several times a day.
Mainline = Master or Release branch
This does not involve feature branches or any other branches at all. Your reaction might involve three letters starting with W, right now. I’d love to see whether your next letter would be a T or an O 😉.
If you are developing a feature that isn’t ready to go live yet, you are allowed to use feature toggles. Other than that everyone works on the same branch, commits to the same branch, and after every commit, the CI Server builds and releases/deploys the software to production—after a successful build. In case of an unsuccessful build, the responsible developer (with the aid of colleagues if necessary) is supposed to fix the build. Mainline must be green all the time. The whole team is responsible, but it usually starts with the one who did the last commit.
This has some significant advantages to the conventional way of using branches and pull/merge requests. It also has some drawbacks.
More on that tomorrow.