When talking to organizations, at first glance, Continuous Integration seems to be a solved problem. The demand for increasingly distributed applications has risen with the bloom of microservices, and development teams have the expectation that every commit should be a build. Continuous Integration has surprisingly become an unexpected bottleneck. In this eBook, we will go through the pillars of Continuous Integration and how to modernize your Continuous Integration practices and platforms.  

This article contains an excerpt from our eBook, Modernizing Continuous Integration. If you like the content you see, stick around to the end where we’ll link the full eBook for you. It’s free – and best of all, ungated.

What Is Continuous Integration?

Simply put, Continuous Integration is build automation. Though, more than just the compiled source code can go into a build; the end product for Continuous Integration is a release candidate. There could be quality steps taken to produce the artifact, such as finding bugs and identifying their fix. Packaging, distribution, and configuration all go into a release candidate. For example, a JAVA application has a JAR, which is then packaged into a Docker Image, and has available all of the environmental configurations the image needs to run. A release candidate is the final form of an artifact to be deployed. 

Modernizing Continuous Integration: Here's a Typical CI Process.

Why Use Continuous Integration?

Having an artifact that is ready to be deployed and/or continued to be vetted (for example, from development to quality assurance environment) is prudent in today’s software engineering organizations. The main output of a software engineer’s work is iterative by nature. Several artifacts can be created before a viable release candidate is made. The ability to build on-demand and start the integration and quality journey begins with a build that can happen multiple times per day. According to Paul Duvall, co-author of Continuous Integration, in a nutshell, CI will improve quality and reduce risk.

Benefits of Continuous Integration

Having an automated Continuous Integration approach frees teams from the burden of manual builds and also makes builds more repeatable, consistent, and available. Having the main work product of a software engineering team (the deployable unit) ready to be deployed regularly is beneficial to the entire software delivery life cycle and allows for consistent collaboration between engineers by avoiding common bottlenecks. 

Repeatability

Externalizing the build instead of being only executed locally by a developer puts more eyes on the build steps. The Continuous Integration configuration starts to have less of an individual snowflake approach and can be an asset the broader team uses. Having a build executed by a system is repeatable and a march towards having consistency. 

Repeatability

Consistency 

The ability to build consistently is one of the major pillars of Continuous Integration. After having repeatable builds, efficiency and consistency start to step in as Continuous Integration practices become more mature on the team. Having a consistent build/artifact is key with maintaining dev-to-prod parity. An example of this would be keeping the environments similar or having the changes between them well-known. With consistency, there is also the ability to have builds more readily available. 

Modernizing Continuous Integration Includes Consistency

Availability

The ability to scale to match the demands of the concurrent builds needed by a team, and the ability to recreate a build, is the availability of the build. Modern containerized builds require more horsepower than just building the application binary. Distributed build systems allow for those builds to be more available. Since the builds are repeatable and consistent, a core tenet of modern software development is to be repeatable at any step of the process. Old builds and previous versions can be available by simply calling a recipe from the past. With the emphasis on having a build available at any time, challenges can arise supporting a wide swath of technology.

Modernizing Continuous Integration Including the Ability to Create a Build of Any Version at Any Time.

Conclusion

We hope you enjoyed this first excerpt of our Modernizing Continuous Integration eBook. In the next excerpt, we’ll go over Continuous Integration best practices and the challenges one can face with CI.

If you don’t want to wait for the next blog post, go ahead and download the eBook today – it’s free and doesn’t require an email address: Modernizing Continuous Integration.