With continuous delivery (CD) almost always in the spotlight, continuous integration (CI) is often left out in the cold. Indeed, it?s been in use for so long and so widely, we often take the model for granted. So what is CI and how can you make the most of it? This blog is intended to answer those questions.
Before we step into examining CI, we need to look back. Software developers often work in small teams and modularity, and need to integrate their changes with the rest of the project code base. Waiting to integrate code creates merge conflicts, bugs that can be tricky to resolve, diverging code strategies, and duplicated effort. Before CI, developers also had a problem of wasted time: they compiled and built their changes multiple times a day on their own machine and had to sit idle waiting for these processes to complete. Integrating the changes from all teams happened only at night on big dedicated ?build? servers and any issues during this build could create further idle time the next morning as developers isolate and resolve last night?s issues.
CI emerged as a solution to this problem; a practice in which all changes are immediately built, integrated, tested and reported on as soon as they are added to the code base. By testing and reporting on any potential defects and conflicts in the code base, they can be identified and amended more quickly.
As part of a CI process, developers share their code and tests by merging changes into a shared version control repository after every small task completion. This approach triggers an automated build system to take the latest version of the code from the shared repository and to build, test, and validate the full master branch. Modern version control systems like Git and others can be used to build short-lived feature branches, where work is isolated.
Teams use build definitions to ensure that every commit to the master branch triggers the automated build and testing processes. Implementing CI this way ensures bugs are caught earlier in the development cycle, which makes them less expensive to fix. Automated tests run for every build increasing test coverage and maximizing quality across all builds.
CI has many other advantages. It leads to more rapid software development, produces deployable software at every step in the development lifecycle, and reduces the time between defect introduction and detection, thus saving time and lowering costs. Moreover, developers minimize risks and repetitive manual processes, and teams receive better project visibility.
CI and Application Release Automation
As we?ve seen, CI tooling blends multiple code branches of a release into an integrated build, allowing developers to perform tests based upon the build. To perform these tests the build artifacts have, by necessity, to be deployed to an environment typically referred to as an integration environment.
This deployment capability of CI tools has led many developers, wishing to push DevOps, to use CI tools beyond their intended purpose and deploy app artifacts to environments other than DEV or Integration. And therein lies the problem: CI tools lack the security, scale, and governance demanded by production environments.
This is where Application Release Automation (ARA) comes in. ARA addresses a broader use case than CI ? including the separation of duties, approvals, compliance audits, auto-scaling ? and is therefore entirely suited to production environments.
Role-based access control, for example, provides greater control over change processes to production environments, while encryption and other safety measures enable IT to securely deploy application artifacts, data and configuration settings.
Some ARA solutions, such as Automic Release Automation, enable DevOps teams to use whichever whatever tools they choose. Jenkins can still be used for CI as one of the many tools making up the toolchain in a continuous deployment pipeline, for instance, but then ARA itself should take over for the actual deployment.
Ultimately, ARA enables organizations to move away from islands of automation and separate practices for PROD and non-PROD. Release coordination is combined with deployment automation across the continuous delivery pipeline. All resulting in faster and more frequent high-quality releases.
