Continuous Integration (CI) and Continuous Delivery (CD) represent a culture, a set of principles and practices that enable developers to deploy software changes more frequently and reliably.
CI/CD is one of the DevOps practices. It also applies to agile practices: automation of deployment allows developers to focus on implementing business requirements, code quality, and security.
Definition of CI/CD
Continuous integration is a development methodology and set of practices in which small changes are made to the code with frequent commits. And since most modern applications are developed using different platforms and tools, there is a need for a mechanism to integrate and test the changes made.
From a technical standpoint, the goal of CI is to provide a consistent and automated way to build, package, and test applications. With a well-established continuous integration process, developers are more likely to make frequent commits, which in turn improves communication and software quality.
Continuous delivery begins where continuous integration ends. It automates the deployment of applications to various environments: most developers work with both production environments and development and testing environments.
CI/CD tools help configure specific environment parameters that are configured during deployment. CI/CD automation also performs the necessary requests to web servers, databases, and other services that may need to be restarted or perform additional actions when deploying an application.
Continuous integration and continuous delivery require continuous testing, as the ultimate goal is to develop high-quality applications. Continuous testing is often implemented as a set of various automated tests (regression, performance, and others) that are performed in the CI/CD pipeline.
Mature CI/CD practices enable continuous deployment: when code successfully passes through the CI/CD pipeline, builds are automatically deployed to the production environment. Teams practicing continuous delivery can afford to deploy daily or even hourly. However, it should be noted that continuous delivery is not suitable for all business applications.
Continuous integration improves communication and quality
Continuous integration is a development methodology based on regulated processes and automation. With continuous integration in place, developers often commit their code to the source code repository. And most teams adhere to the rule of committing at least once a day. With small changes, it is easier to identify defects and various problems than with large changes that have been worked on over a long period of time. In addition, working with short commit cycles reduces the likelihood of multiple developers changing the same piece of code, which can lead to conflicts during merging.
Teams implementing continuous integration often start by setting up a version control system and defining a workflow. Even though commits are made frequently, feature implementation and bug fixes can take quite a long time. There are several approaches to controlling which features and code are ready.
Many use feature flags—a mechanism for enabling and disabling functionality at runtime. Functionality that is still in development is wrapped in feature flags and deployed from the master branch to production, but disabled until it is fully ready for use. According to a recent study, 63 percent of teams using feature flags report improved testability and software quality. There are special tools for working with feature flags, such as CloudBees Rollout, Optimizely Rollouts, and LaunchDarkly, which integrate with CI/CD and allow configuration at the feature level.
Another way to work with features is to use branches in a version control system. In this case, you need to define a branching model (such as Gitflow) and describe how code gets into the development, testing, and production branches. Separate feature branches are created for features with a long development cycle. After completing work on a feature, developers merge changes from the feature branch into the main development branch. This approach works well, but can be inconvenient if many features are being developed simultaneously.
The build phase involves automating the packaging of the necessary software, database, and other components. For example, if you are developing a Java application, CI will package all static files, such as HTML, CSS, and JavaScript, together with the Java application and database scripts.
CI will not only package all software and database components, but also automatically perform unit tests and other types of testing. Such testing allows developers to get feedback that the changes they have made have not broken anything.
Most CI/CD tools allow you to run the build manually, on commit, or on a schedule. Teams need to discuss a build schedule that works for them based on team size, expected number of daily commits, and other criteria. It is important that commits and builds are fast, otherwise long builds can become a barrier for developers trying to commit quickly and frequently.