More and more companies want to use continuous integration and continuous delivery, but with so many programs to use, it's really confusing knowing where to start.

Everyone who's invested in DevOps, loves CI/CD. CI gives you a consistent and automated way to build, package, and test applications. CD then picks up the ball by automating the delivery of applications. What's not to love?

Continuous Integration (CI)

integration-is-hard-false-start-doing-continuous-integration.jpg

What Is Continuous Integration?

Continuous integration is a DevOps software development practice where developers regularly merge their code changes into a central repository, after which automated builds and tests are run. Continuous integration most often refers to the build or integration stage of the software release process and entails both an automation component (e.g. a CI or build service) and a cultural component (e.g. learning to integrate frequently). The key goals of continuous integration are to find and address bugs quicker, improve software quality, and reduce the time it takes to validate and release new software updates.

Continuous Integration (CI) is the practice of automating the build and testing of code every time a change is made — and committing that code back to a central repository.

One of the fundamental cornerstones of Continuous Integration is that it encourages breaking up development tasks into small bite-sized pieces that can be performed frequently by every developer on the team.

Each new code commit triggers a consistent, automated build and test process — often called a “pipeline” — to report any defects found during compilation or testing as quickly as possible

Continuous Integration is one of the key components of DevOps Automation.

What are the Benefits of Continuous Integration?

By implementing Continuous Integration, software development teams benefit from:

Continuous Integration Makes it Easier to Fix Bugs

Identifying issues sooner makes it easier for developers to fix errors, vulnerabilities, and defects in the code. What’s more, this helps to ensure that an issue will be fixed correctly, resulting in a build that’s issue free and working as quickly as possible.

Continuous Integration Reduces Project Risk

Encouraging small, modular changes to the code enables new functionality to be backed out of a release more quickly, or even prevented from entering the main code stream altogether. This minimizes the impact on other developers.

Continuous Integration Improves Software Quality

Maximizing the value of CI means detecting as many issues as possible in each integration build, through automation. This increases the breadth, depth, and repeatability of the tests while avoiding manual testing.

Continuous Integration Leads to Higher Productivity

Automating these tasks frees up developers to focus on higher-value feature development.

How Does Continuous Integration Work?

The nine steps of Continuous Integration:

Developers check code into the version control system’s staging repository.

The Version Control System (VCS)or code repository notifies the CI server that a commit has occurred. Or, the CI server polls the repository periodically looking for commits.

The CI server starts the build process on a build server.

The code containing the latest commit — ideally just the minimum file set — is checked out of the repository into a local workspace on the build server.

The changed code is built, analyzed, and tested.

Important results are reported back to the CI server, along with any important details and files that need to be retained.

The CI server sets the final — Pass / Fail — the result of the build.

If the build met the success criteria, then the committed change may proceed through the development cycle - transferred to the real repository or merged to the main development stream. If the build failed, the committed changes are blocked from proceeding until those issues are resolved.

The CI server notifies any parties who have registered interest in the build. They can then log into the CI server to view the status plus any additional information.

Why Continuous Integration Is Important In Software Development?

Continuous Integration accelerates software development to avoid these common pitfalls of development:

Frequent code integration helps to eliminate code conflicts and code incompatibility
Developers are encouraged to have the most up-to-date repository code when working
Reduces the refactoring complexity
Quality gates ensure only clean, working and tested code makes it to the repository

Reduces repository commit bottlenecks

With a CI pipeline, every change is integrated, tested and verified which brings the commit closer to being a viable release candidate

How Does Static Analysis Extend Continuous Integration?

Static analysis is a natural addition to any CI development process and done correctly, adds the possibility for almost immediate feedback of new coding issues, specific to the branch or commit containing them. This provides the opportunity for quality gates to prevent those issues from ever entering the main codestream and needing to be resolved later — improving development efficiency.

Static analysis complements other verification and validation techniques, such as dynamic testing, because:

Static analysis provides coverage of all possible execution paths, whereas for dynamic analysis error or fault conditions of the code that are typically very difficult, or even impossible, to induce at runtime.
Static analysis is very cost-efficient in terms of detecting bugs earlier in the lifecycle — and it requires much less time to run.
Issues detected with static analysis, prior to dynamic tests being written also saves downstream costs of reworking those dynamic tests, once the issues have been resolved — most dynamic tests are quite dependent on the code itself and so a change has an impact also on the tests.

The ideal static analysis engine for CI processes only modified code and affected execution paths, rather than processing the entire codebase all the time, and reports the impact of those changes.

Since static code analysis operates on source code and doesn’t have to actually execute the code, it can perform a complete analysis of the submitted code changes in a specific time frame. In addition, static code analysis doesn’t require specific test cases to be written.

To be effective in complementing CI, a static code analysis tool must be fast, scalable, and automated.

Continuous Integration -vs- Continuous Delivery?

Continuous Integration (CI) and Continuous Delivery (CD) are both software development practices.

CI is used during the build and test phase. CD is used once changes are committed. The ultimate aim of CD is to always have validated and verified code in the code repository — or version control system — ready for release.

Continuous Delivery & Continuous Deployment

What is continuous delivery?

AWS notes that continuous delivery is a DevOps software development practice where “code changes are automatically built, tested, and prepared for a release to production. Continuous delivery expands upon continuous integration by deploying all code changes to a testing environment and/or a production environment after the build stage.”

What is Continuous Deployment?

Continuous Deployment (CD) is a software release process that uses automated testing to validate if changes to a codebase are correct and stable for immediate autonomous deployment to a production environment.

The software release cycle has evolved over time. The legacy process of moving code from one machine to another and checking if it works as expected used to be an error-prone and resource-heavy process. Now, tools can automate this entire deployment process, which allows engineering organizations to focus on core business needs instead of infrastructure overhead.

Continuous Deployment Tools

Establishing continuous deployment requires substantial engineering investment. The following is a list of tools that are needed to build a continuous deployment pipeline.

Automated testing

The most critical dependency for continuous deployment is automated testing. In fact, the entire chain of continuous integration, delivery, and deployment depends on it. Automated tests are used to prevent any regressions when new code is introduced and can replace manual reviews of new code changes.

Rolling deployments

The distinguishing feature between continuous deployment and delivery is the automated step of activating new code within a live environment. A continuous deployment pipeline must be able to undo a deployment in the event that bugs or breaking changes are deployed. Automated rolling deployment tools like green-blue deploys are a requirement for proper continuous deployment.

Monitoring and alerts

A robust continuous deployment pipeline will have real-time monitoring and alerts. These tools provide visibility into the health of the overall system and into the before and after the state of new code deployments. Additionally, alerts can be used to trigger a rolling deployment ‘undo’ to revert a failed deploy.