Why does Continuous Integration(CI) matter?

Don't feel like reading today?  Check this out in our Podcast form on Podcast 06

Continuous Integration(CI) Systems are more popular than ever. Why wouldn't they be when they simultaneously reduce expenses and improve the quality of the output. They do this through improved communications between teams, identifying problems as early as possible, and providing a production like environment most developers don't have on their local computers for testing. Before we get to far ahead of ourselves let's explain a few things.

Let's start off with what Continuous Integration(CI) is. Continuous Integration is a set of tools combined together to test either an application or set of applications either on a schedule or when triggered. Triggers could be just about anything.( eg. check in on a branch in a version control system, a new file being placed in a specific location, a button pushed on a website) Once the tests are complete a report is generated whether they fail or succeed. If they fail generally everything stops until someone reviews, fixes and then re-triggers the CI Process. If it succeeds then people do everything from pushing the code to the next tier, i.e. from Development to User Tests, on the process or even to production.

So it happens like this: Developer A fixes a bug in a piece of code That code breaks developer B's code that calls to that code When developer A's code is tested in the CI Environment an alert is sent to the team letting everyone know there is a problem. Developer A should then go look at the problem and try to fix it. Once resolved and the tests in the CI all work the CI tool can then push the code to the next environment in the change for further testing or maybe even production.

CI keeps teams from running to long with errors or bugs in the code. To get the most out of it you must have good tests written with the code. The amount of code that has a test associated with it is represented by a percentage normally called Code Coverage.  One hundred percent(100%) is very difficult if not impossible to reach in most cases. The higher the percentage of code coverage the better. But there is a diminishing rate of return somewhere between eighty(80%) and ninety(90%) percent code coverage. This means that you will spend more time writing tests than the time you will save by having the tests.

How does it help? The longer you wait to test something the harder it will be to determine what change you made that caused the problem. When your code is small, it's not that hard to figure out where the problem is. When you get to large code bases with lots of lines of code across lots of files it gets considerably harder. CI makes it easy to check your code. It allows you to get a quick sanity check of your code and let you know that you didn't cause any major problems.

On some of the more advanced teams I have worked with, the bugs they are fixing have tests written for them. So that when you are done doing the fixing, it you will know if it was successful. This also prevents you or someone else from re-introducing a bug in the future because you are testing for it.

It can also signal to testing staff that they can test for a bugs resolution. That makes them more efficient because they aren't testing things that aren't fixed yet. Testers are also often responsible for pushing the code to either a User Acceptance Testing(UAT)/Staging environment and/or production.

Basically it will save the world? No, it won't save the world but it will help your team tremendously in the long term. Make no mistake the process of smoothing out the processes and implementing the software are no small feet done in an afternoon. However, if you take it in small bites and solve the whole problem in iterations of small chunks it will start paying benefits within a few days to a week. A lot of the timing depends on where you are starting from. If you already do test driven development then the time to a return on your investment will be short. If all you do is copy files between machines and hope they work after someone "makes a few changes" to get them working, then it could take a lot longer. This is a very powerful concept in the grand scheme of DevOps. When well executed the return on time spent implementing it should pay off in short order. As with most concepts in DevOps the farther you are from the ideal when you start, then the bigger and faster the payoff will be.