Introduction to Continuous Integration and Continuous Delivery

Software Development Life Cycle

Software development follows a flow, starting with identifying new features, planning, doing the actual development, committing the source code changes, running builds and tests (unit, integration, functional, acceptance, etc.), and deploying to production.

With a traditional waterfall software delivery approach, developers could work independently for a very long time. They would not have a clue about how many issues they would run into during the integration phase.

In order to address this issue, the Agile software development model was introduced. Agile changed the way software development teams worked. One of the key principles of this methodology was delivering working software frequently. The focus moved to releasing incremental software, rather than big bang waterfall releases which took months and years.

Delivering software frequently meant producing stable code for every incremental release. It was quite a challenge to integrate changes from various developers on the teams. This led to software teams looking for better approaches. Continuous Integration (CI) offered a ray of hope and started to gain in popularity.

Continuous Integration (CI)

Continuous Integration is an agile engineering practice originating from the extreme programming methodology. It primarily focuses on automated build and test for every change committed to the version control system by the developers.

In order to implement Continuous Integration, you will need:

• A version control system
  It stores all the source code checked in by the teams, and acts as the single source of truth.
• Automated build and unit test
  It is not sufficient if the code written by a developer works only on his/her machine. Every commit that makes it to the version control system should be built and tested by an independent continuous integration server.
• Feedback
  Developers should get feedback on their commits. Anytime a developer’s change breaks the build, they can take the necessary action (example: email notifications).
• Agreement on ways of working
  It is important that everyone on the team follows the practice of checking-in incremental changes rather than waiting till they are fully developed. Their priority should be to fix any build issues that may arise with the checked-in code.

Continuous Delivery

Continuous Delivery is a logical extension of Continuous Integration. While Continuous Integration lets you automate the software build and test process, Continuous Delivery automates the full application delivery process by taking any change in code (new features, bug fixes, etc.) all the way from development (code commit) to deployment (to environments such as staging and production). It ensures that you are able to release new changes to your customers quickly in a reliable and repeatable manner.

Incorporating Continuous Delivery practices will make your overall release process painless, reduce the time to market for new features, and increase the overall quality of software thereby leading to greater customer satisfaction. It can also significantly reduce your software development costs as your teams will prioritize releasing new features over debugging defects.

Continuous Deployment

Oftentimes, the terms Continuous Delivery and Continuous Deployment are used synchronously by many, but in reality these concepts have a different meaning.

While Continuous Delivery gives you the capability to deploy to production frequently, it does not necessarily mean that you are automating the deployment. You may need manual approval prior to deploying to production, or your business may not want to deploy frequently.

Continuous Deployment, however, is an automated way of deploying your releases to production. You need to be doing continuous delivery in order to be able to perform automated deployment. Companies like Netflix, Amazon, Google, and Facebook automatically deploy to production multiple times a day.

Deployment Pipelines

Deployment pipelines (or Continuous Delivery pipelines) are the cornerstone of Continuous Delivery as they automate all the stages (build, test, release, etc.) of your software delivery process.

There are numerous benefits to using Continuous Deployment pipelines. An automated pipeline allows all stakeholders to monitor the progress, eliminates the overhead of all the manual work, provides quick feedback, and more importantly builds confidence on the code quality.

The deployment pipeline run starts with a developer committing source code change into a version control repository. The CI server detects the new commit, compiles the code, and runs unit tests. The next stage is deploying the artifacts (files generated from a build) to staging or a feature test environment where you run additional functional, regression, and acceptance tests. Once all the tests are successful, you are ready to deploy into production. In case of failure during any stage, the workflow stops and an immediate feedback is sent back to the developer.

Tools for Deployment Pipeline

In order to automate the various stages of your deployment pipeline, you will need multiple tools. For example:

• a version control system such as Git to store your source code
• a Continuous Integration (CI) tool such as Jenkins to run automated builds
• test frameworks such as xUnit, Selenium, etc., to run various test suites
• a binary repository such as Artifactory to store build artifacts
• configuration management tools such as Ansible
• a single dashboard to make the progress visible to everyone
• frequent feedback in the form of emails, or Slack notifications.

And that’s not all. You will also need a single tool that can bring all these tools together to achieve CI/CD goals which is to automate software delivery.