CI server has its name after a set of practices first introduced by Martin Fowler in 2000. The keystone is continually integrating the working code into a single branch as often as possible, at least daily. This single branch in git is usually called “master”, in SVN it’s “trunk”.
Profits of continuous integration
You avoid an integration hell
When I was a junior developer working on my first full-time developer job, I remember how proud and happy I was when I was assigned quite a difficult task for the first time. It took me about two weeks to implement it. I developed it in a separate SVN branch, and, being a junior developer unaware of the continuous integration concept, I never pulled changes from the trunk until I was done. And when I did, there was a massive amount of conflicts, and I had tough times fixing them. This situation is called integration hell. If I’ve pulled the code daily, I’d have had a small amount of easily resolvable conflicts.
You find bugs earlier, ending up with fewer bugs as a result
Pulling code daily is only one side of the coin. The second one is pushing it in the main branch daily. Usually, it’s way harder, because you must be sure that this code works. Otherwise, your changes break the code of any team member who decides to pull the latest changes. So it’s too tempting to steer away. But be alert. Remember, the bigger your pull request, the harder it is to review it, and the more likely there is a bug in there. Besides, the less often you push changes, the later this bug is found out — either accidentally by some team member, or by the QA team.
You can deploy more frequently
If your main branch is stable at all times, you can deploy more often, increasing your product’s time to market. But it doesn’t mean there will be no bugs. But what is easier, to find a bug in a code that has been written during yesterday or in a code that has been written during last week or last two weeks? And if you’ll have to rollback, what is preferable from a business-perspective: to rollback yesterday’s amount work or to roll back last week’s amount of work? So, in spite of inevitable bugs, more frequent deployments end up being less fragile, opposing to big-bang-style weekly deployments.
In theory, you don’t need a CI server to practice continuous integration. But it hugely alleviates your development process, allowing you to focus exclusively on business-features. So what exactly does CI server bring to a table?
CI server increases work ethics
We all know that we should commit only code with all tests passed. Anyway though, sometimes we forget to pass tests before commit. “What a big deal“, you might think. Think again. Tests reflect a state of a code: whether it works, or it doesn’t. If the rest of the team pull your changes and all of sudden find out that their tests don’t pass anymore, they lose the ground beneath their feet. They can’t be sure anymore that their code works because they simply don’t know: tests do not pass.
If your team has a code style guide, apparently it’s implied that everyone follows it. However, we’re all human beings. We might just for some reason leave a curly brace on the same line, while the code style guide tells the opposite.
Long story short, assumptions don’t work. Any assumption must be reinforced by some software tools. And CI server, among others, is precisely such a tool.
CI server reinforces de-facto standard industry best practices
Almost twenty years ago, Joel Spolsky, a guy behind StackOverflow, coined his classical “The Joel Test”. This list was actual back then as well as it is now. For many companies, it has been serving as a maturity checklist. Some even put this filled checklist in their vacancy description. CI server brings you way closer to checking items 2 and 5.
One-step build
What’s the problem in a two-step build, you might wonder, or three-step build? It’s not that much anyway, right? Right, but your system evolves, so does the process of its deployment. If it takes three manual actions today, it will take thirty manual actions a year later. This process is error-prone and exhausting. We, developers, don’t like to do things manually. It’s boring. The tension is too high, and willpower has limits. We try to avoid it at all costs. “Nah, no point in deploying this stuff today, I’ll do it tomorrow” — that’s where you’re going to land. Hello, big-bang deployments!
Bug-fixing-first
Joel spotted one of the reasons why this is crucial:
In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix.
It’s such a big thing that it’s part of the waste types in Lean development. It’s one of the cornerstones of the whole Kanban philosophy. Besides, it’s decreasing the team’s morale and destroys its momentum. So yes, it’s that important.
CI server notifies you if you’ve made a bug, and does it in a matter of minutes. Good CI server makes these notifications inescapable. So, effectively, this approach means fewer bugs in production.
Besides, there is a psychological aspect of this whole thing. Fixing-a-broken-test-asap philosophy indicates that your team is serious about code quality. It is a broken windows theory in action. One broken test today that no one pays attention to — and you get dozens of broken tests tomorrow. CI server gets you a step closer to getting deadly serious about quality: it just makes it harder not to notice red tests. Up to the point of making you fix that test if you want your stuff deployed. And you know yourself, it’s only for the better.
Writing tests
Of course, this implies that you have a decent test-suite in place. You might have none. No worries, the key is to start. However paradoxically, a failed test creates a positive feedback loop, promoting developers to write more tests. The failed test could be that “A-ha!” moment when you see the tangible effect of writing them. So if you don’t have any tests, start with one simple test. Also, build a habit to write at least one test daily. Start small but be consistent. Consistency is the key.
In a month, your code’s quality increases drastically, I promise.
CI-server of my choice
I recommend Buddy. It can be adopted by any team of any experience. It’s painless to set up. And your app’s deployment time is blazingly fast. It has an impressive feature pack, and the pricing policy is affordable. All in all, it’s worth the money.
In closing
Basically, the CI server reduces the human-factor through reinforcing best-practices and automating routine tasks.
To me, it’s the difference between being an amateur and being a professional.
