5 reasons to use continuous integration

Frank Zinghini

Founder & CEO
today
timer

At its core, continuous integration (CI) is really a simple thing, and it provides teams an opportunity to solve many types of software problems very early on. Every time code is checked in, the whole application is rebuilt and checked both for compilation problems and, potentially, a variety of other issues—including issues that can be identified through various static analysis tools.

Implementing a CI process can help ensure that there are no obvious syntactic errors, and that any compile or build warnings that exist are warnings you’re willing to accept. If you choose to implement stringent CI policies, you can configure them so that check-ins with certain warnings result in a build failure.

Some software companies don’t use continuous integration. We understand why they might choose not to do it. You need to invest some time at the beginning of a project to get the infrastructure in place in order to do it right. For others, they feel that don’t know how to fit it into their current development process, or perhaps they don’t realize the benefits of running continuous integration.

At AVI, we see continuous integration as an important part of our development process, because we realize the payoff goes beyond catching mistakes in the code. Here are five key reasons we use Continuous Integration.

5 vital reasons we use continuous integration

1) Better code

While CI gives you the framework to catch errors that would break a build, and to find security issues (more on that in a moment), one sure byproduct of using CI is cleaner and more efficient code. In addition, your automated documentation can become a lot better, your visual consistency within the code can improve greatly, the code can be easier to maintain, and it can be better documented overall.

For example, at AVI, we use continuous integration to verify that every function has a comment on it, and to ensure that programmers didn’t simply copy and paste comments from other functions. So when an application has a quarter of a million lines of code and several programmers have been working in it, we’re assured of having common and consistent notation of that code.

If you add code analysis steps to your CI, they can analyze the quality of the code and determine, for example, whether a function is too complicated. The person who wrote that function may know exactly what it does, but six months later when somebody else looks at it, they might be totally lost. With code analysis integrated into the build, you can force that initial developer to create better code, so that later on the other developers will  be relieved that it isn’t 20,000 lines long or have 40,000 “if” statements in it.

Because of the upfront investment that’s required to set up this methodology, it probably isn’t a good fit for quick projects or small apps. But for large projects that take longer to develop, that initial investment in time and effort  will be repaid many times over.

2) Better programmers

If you use CI to maintain specific coding standards, it may initially create an annoyance that your developers will have to get past, but they will be better for it in the long run. If you have people who aren’t good at commenting, or who tend to use sloppier coding processes, they may feel restricted by CI because they will have to redo their work simply because it doesn’t match the required standard. For example, when they check in their code, the build could fail simply because they forgot to capitalize a comment.

But as time goes on, your engineers will start to get better about not putting problems into the code in the first place. They won’t want the aggravation of the process yelling at them, so they begin adhering to the standards from the start. And before long, they’re programming at a higher quality standard as a matter of course, without really thinking about it.

We’ve found that often, when these programmers move on to other projects that don’t use CI in this way, they continue to follow the higher standards anyway. This method has helped them to become better programmers.

3) Easier to maintain

When you implement continuous integration on top of a large project with several developers and hundreds of thousands of lines of code, you can use CI to create a unity and simplicity that makes the code easier to maintain.

CI can help ensure that everybody’s code manifests itself in a similar way—using similar notation, similar coding schemes, etc.—and makes it much more readable by everybody. Your code becomes much easier to maintain, and easier to fix.

And the less time you spend maintaining code, the more money you save on the project.

4) Security

In recent years, various tools have been introduced that look specifically for security vulnerabilities in your code; patterns of code that attackers have been known to exploit. There’s a vast range of such patterns—things like buffer overflows, SQL injections, and many more—and these tools know how to recognize and flag them. Catching things like this at build time isn’t just a huge benefit of CI, it’s become a necessity. If you catch a security issue in your code early on during development, it might cost a couple of hours of work to fix. But if the bug isn’t identified until the end of the development cycle, you could find yourself implementing major changes at a time when you’re up against deadlines. And even worse, if it gets into the wild and someone exploits it to harm your business, the results could be a disaster.

In short, don’t wait until the end of a project to run a security check on it. From the very first piece of code you check in, you should be running those tools to the greatest extent practical.

5) Better processes

Not everyone uses continuous integration. For some projects, especially small ones, it’s just not worth the upfront costs of setting up the infrastructure. And for some software companies, CI simply isn’t a priority. In the latter case, that doesn’t necessarily mean that these developers don’t have sound processes in place: they might very well be doing a fine job without CI. But software companies that do implement continuous integration are giving themselves an edge: they’re relying on smart, automated processes to produce the best possible applications that they can. They’re implementing a system that standardizes their coding, their testing, and their other activities so that the final product contains secure, efficient, robust, and reliable code.

AVI realizes the value of continuous integration, and while our clients may not always realize it, they reap the benefits of it every time they use our software.

Next steps