CI versus CI: Does Continuous Integration lead to Continuous Improvement?

Is Continuous Integration a toolset, a process, or a change in culture and expectations? The longer CI is around, the more it becomes apparent that all those elements must work together to make a real impact. Doing Agile has been a successfully project management methodology in the technology world for many years. But it is one thing to have an Agile team and quite another to be able to design, develop, and deploy software in an ongoing cycle of improvement. With the right tools and processes for continuous integration, development faces fewer bottlenecks for productivity and overall quality.

Scott Hickey, Principle Enterprise Architect at Mutual of Omaha, observed this phenomenon following the implementation of CI in his own organization. “Even though we had a lot of people trying to do an Agile methodology like Scrum, they were doing it from a project management perspective and not from a software engineering perspective.” It was tools like the Jenkins automation server that turned things around. “Before, there wasn’t really any emphasis on tests. It was just about having a repeatable build. Now we are building on every check in. I don’t think you can do Agile without that continuous feedback.”

The build: where the product meets the process

Hans Dockter, Project Lead at the Gradle Open Source Project, noted a distinction between Continuous Integration as a process and CI as a product category. This is especially important when considering how the requirements of mobile have made CI a necessity rather than a luxury. “In the CI process, the build tool is essential. For example, in Android it is everything. It is where you compile, obfuscate, run tests, and deploy to the apps store.” In contrast, “CI as a product provides multiple services. For example, it tracks history across builds and sends notifications with updates on what was successful and what was not.”

Dockter believes the build will become more and more the heart of CI. Now that builds can happen with great frequency at a low cost in time and resources, it’s possible to use this quality control checkpoint in a much more iterative and Agile fashion. When it comes to a successful build, CI products are all about managing, monitoring, and improving the process.

A change in tools and tactics requires a shift in habits

Changes in how developers work, what’s expected of them, and how they can help the team improve productivity and quality as a whole are all critical aspects of Continuous Integration as a culture. This shift has practical implications for developers’ day to day work. According to Scott, “At the enterprise level, we need to get all of our development teams used to checking in codes and tests.” The Mutual team uses tools such as Sonar with Jenkins and Gradle to make this happen.

“Now I’ve got constant feedback and everyone can see it. We can tell historically if code coverage is trending up or down. I know if I have a bunch of code being checked in and not very many tests, my code quality is probably not going to be very high. Even a project manager or software development manager can recognize these metrics—they are easy to understand. It’s important to have a way to see those automated tests and get people used to seeing the importance.” When developers know that everyone can see the amount of coverage they have on their code, they are motivated to take the time to write appropriate tests to submit with their code each day.

Tools for performance testing in CI

Performance is another area where CI/CD tools can empower teams to do more testing, do it better, and do it earlier in the development process. Blazemeter CEO Alon Girmonsky believes that performance testing should be democratized. “Everyone should be able to test for performance regardless if they are Engineers, DevOps, Product Managers, etc. We shift performance testing to the development side of DevOps, even for things like scalability and load testing.”

Dave Karow, Blazemeter’s Director of Product Marketing, spoke more about the responsibility of developers to improve code quality. “It used to be an end of release cycle performance checkbox. Now, it is shifting into testing that happens throughout the dev cycle and maybe even all the way into integration testing. You are building testing as you are building code so you already know the performance parameters for unit tests before you start writing. You are never waiting for the performance guys to script a test to find out if your application performs.”

This shift to the left may place an additional burden on developers to think ahead more than they are used to. Certainly, DevOps teamwork will come into play as Operations’ insights into performance are critical to ensuring that appropriate tests are being designed and written for today’s cloud environments. But tooling that gives developers a simpler way to create and run performance tests will give them more confidence in their code and lead to fewer frustrating rewrites down the road. Since the work of Continuous Integration is never done, it might as well be work that is more productive and satisfying for everyone involved.