Continuous Integration
Intro
What is "Continuous Integration", also known as CI?
It's a common misunderstanding to say that running tests automatically when you commit code is "CI". There are even some services that confuse the issue that way, like Travis CI.
No, Continuous Integration is something much much simpler:
Continuous Integration is a way of working, where your code is merged into the common repository often.
That's it. Simple, right? You don't create long-lived branches where you work for weeks and then try to merge to the master branch. You either work on very short-lived branches, or you have a long-lived one but merge from it into the master branch often.
Some of the benefit of continuous integration are:
- Because you merge often, you have fewer conflicts
- Because you merge often, your code is delivered to users faster
- Because everyone merges often, coordination is improved (or rather, uncoordination is noticed)
- Because you have to merge at sensible points, you will break down your tasks better.
- Because you see the changes in action incrementally, you will avoid going in the wrong direction (you will pivot faster)
The part where automatic test runners come in is that you need to be confident to be able to do continuous integration. If every time you merge into master everything breaks, then you are just going to be frustrated.
If there is more than one person working on the code and everytime someone else merges everything breaks, you are going to be pissed off.
And since frustration and anger are unpleasant, we should endeavour to make continuous integration easier, using both tools and a mindset that are conductive towards continuous integration.
In the previous chapters we:
- Learned how to add tests to our code
- Learned a little about how to use git
- Learned how to share things in gitlab / github
- Packaged our app "The Right Way"
Let's combine those things.
We will configure GitLab CI so that whenever we push code to the public repository things are tested automatically. This includes testging when pushing code to the master branch, thus validating the state of our future releases, and also when pushing code to other branches, thus validating whether they are in a state that allows merging into master.
By having those tests run automatically, if our test coverage is good, we will have confidence that the code works and will be enabled to merge frequently into master. And then we will have continuous integration.