Continuous Integration, Continuous Delivery, Continuous Deployment. (CI/CD)

Continuous Integration, Continuous Delivery, Continuous Deployment. (CI/CD)

Continuous Integration

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.

According to Martin Fowler, “Continuous Integration (CI) is a software development practice where members of a team integrate their work frequently; usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible”.

ci-process

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 Integration primarily solves the development part of the workflow. However, there is more to software delivery than just feature development and integrating the changes. There is testing (manual, automated) and release process (actual deployment to customer or production).

In the pre-DevOps era, each team was responsible for their own work. The development team would take care of feature development. That’s where their job ended. They would then throw it on over to the quality assurance (QA) team. The QA team would run all the extended test suites (manual and automated). If things worked fine, they would hand the features off to the operations team, who would then ultimately roll out the new features into production and manage them.

Each of these teams worked in silos. The release processes were mostly manual and error prone leading to longer and painful release cycles. Every time something went wrong, a massive amount of time was spent trying to get to the root cause of the issue, let alone the blame game. All this resulted in a lot of wasted time at various levels of the organization.

In reality, every single team should be equally responsible for the release of the new software, which means all these teams need to work in close collaboration with each other. The DevOps movement, which originated from Agile software development, strongly emphasizes the need for collaboration amongst the various teams involved in the software delivery process. In addition to close collaboration, automation of each of the stages of the software delivery process and constant feedback cycles are also considered extremely important. Continuous Delivery provides a framework to achieve the goals of DevOps through automation, and continuous feedback loops.

Dev and Ops Collaboration

Dev & Ops Collaboration

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.

According to Martin Fowler, who coined the term Continuous Delivery,

“Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.

You’re doing continuous delivery when:

a. Your software is deployable throughout its lifecycle.
b.
Your team prioritizes keeping the software deployable over working on new features.
c. Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them.
d. You can perform push-button deployments of any version of the software to any environment on demand.

(…)

To achieve continuous delivery you need:

  • a close, collaborative working relationship between everyone involved in delivery (often referred to as a DevOps culture)
  • extensive automation of all possible parts of the delivery process, usually using a deployment pipeline*”.

*We will cover this in a bit more detail later in this chapter.

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 synonymously 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.

Oftentimes, the terms Continuous Delivery and Continuous Deployment are used synonymously 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.

Continuous Integration, Continuous Delivery, Continuous Deployment

Continuous Integration, Continuous Delivery, Continuous Deployment

Whether you are doing Continuous Delivery or Continuous Deployment, you know by now that you need a deployment pipeline. Next, let us take look at what deployment pipeline is.

Reference: https://courses.edx.org/courses/course-v1:LinuxFoundationX+LFS167x+2T2020/

Comments are closed.