What is Proper Continuous Integration?

Marko Anastasov - Oct 4 '18 - - Dev Community

Continuous integration (CI) is confusing. As with all ideas, everybody does their own version of it in practice.

CI is a solution to the problems we face while writing, testing and delivering software to end users. Its core promise is reliability.

A prerequisite for continuous integration is having an automated test suite. This is not a light requirement. Learning to write automated tests and mastering test-driven development takes years of practice. And yet, in a growing app, the tests we’ve developed can become an impediment to our productivity.

Are We Doing CI?

Let's take two development teams, both writing tests, as an example. The first one's CI build runs for about 3 minutes. The second team clocks at 45 minutes. They both use a CI server or a cloud-based CI service that runs tests on feature branches. They both release reliable software in predictable cycles. But are they both doing proper continuous integration?

Martin Fowler recently shared a description of an informal CI certification process performed by Jez Humble:

He usually begins the certification process by asking his [conference] audience to raise their hands if they do Continuous Integration. Usually most of the audience raise their hands.

He then asks them to keep their hands up if everyone on their team commits and pushes to a shared mainline (usually shared master in git) at least daily.

Over half the hands go down.

He then asks them to keep their hands up if each such commit causes an automated build and test. Half the remaining hands are lowered.

Finally he asks if, when the build fails, it’s usually back to green within ten minutes.

With that last question only a few hands remain. Those are the people who pass his certification test.

Software Development or a Sword Fight?

If a CI build takes long enough for us to have time to go practice
swordmanship
while we wait, we approach our work defensively. We tend to keep branches on the local computer longer, and thus every developer's code is in a significantly different state. Merges are rarer, and they become big and risky events. Refactoring becomes hard to do on the scale that the system needs to stay healthy.

With a slow build, every "git push" sends us to Limbo. We either wait, or look for something else to do to avoid being completely idle. And if we context-switch to something else, we know that we'll need to switch back again when the build is finished. The catch is that every task switch in programming is hard and it sucks up our energy.

The point of continuous in continuous integration is speed. Speed drives high productivity: we want feedback as soon as possible. Fast feedback loops keep us in a state of flow, which is the source of our happiness at work.

So, it's helpful to establish criteria for what proper continuous integration really means and how it's done.

The 10 Minutes Test

It's simple: does it take you less than 10 minutes from pushing new code to
getting results
? If so, congratulations. Your team is equipped for high performance. If not, your workflow only has elements of a CI process, for lack of a better term. But, this slowness develops wrong habits and hurts the productivity of all developers in a team. This ultimately inhibits the performance of the company as a whole.

Nobody sets out to build an unproductive delivery pipeline. Yet, we're busy enough writing code until we feel like a boiling frog — we don't notice the change until we accept it as the way things just are. Of course our build takes long, we have over 10,000 lines of code!

The Light at the End of the Tunnel

But, things don't have to be this way. Regardless of how big your test suite is, parallelizing tests can cut waiting time down to just a couple of minutes or less. A fast hosted CI service that allows you to easily parallelize tests and scale as much as you need can make a big difference. This is why for us at Semaphore, providing the fastest CI/CD performance is one of the core product principles. By parallelizing tests, you can reduce the time you spend deciding what to do while you wait, and keep your team in a state of flow.


Originally published on Semaphore blog. Happy to share on dev.to — please send your feedback in comments. ✌️

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player