Continuous Delivery

 

What Is Continuous Delivery?

Continuous delivery (CD) is an application development practice that involves automatically preparing code changes for release to a production environment. Combined with continuous integration (CI), continuous delivery is a key aspect of modern software development. Together, these two practices are known as CI/CD. 

Properly implemented CI enables developers to deploy any code change to testing and production environments late in the software development lifecycle (SDLC). Developers can thus rely on build artifacts that have passed standardized test processes and are ready for deployment. 

With continuous delivery, developers can automate various tests (not just unit testing) to verify multiple aspects of software updates before releasing them to the customer. Automated tests might include API testing, load testing, functional and UI testing, integration testing, and so on. These tests help developers assess updates more thoroughly and identify issues before deploying a release to production. 

In a cloud-based deployment, developers can easily and cost-effectively create and replicate multiple testing environments. When working on premises, dynamically creating test environments was traditionally more difficult. Kubernetes is helping organizations effectively automate CI/CD processes across clusters of nodes, both in on-premise data centers and in the public cloud.

Why Continuous Delivery?

Continuous delivery has several advantages over traditional waterfall-style development:

  • Simpler releases—development teams spend less time preparing codebases for release and don’t combine multiple changes into a large, complex release. Instead, developers update and release code in small increments—ideally, every time they make a change.
  • Easier maintenance—minor releases quickly reveal bugs in new code. When software is frequently deployed to production, it is easy to identify production issues, isolate a recent change that caused the issue, fix it, test and redeploy. 
  • Improved development velocity—in a continuous delivery environment, developers can iterate on software rapidly and deliver value to customers faster. New features can be accessed by customers much more quickly, and when customers have new requirements, development teams can rapidly respond to them.
  • Improved quality—continuous delivery makes releases more predictable, more reliable, and of higher quality. CD does not prevent bugs, but can catch them earlier in the development lifecycle and reduce their impact on customers.
  • Less downtime – removal of manual steps minimized the amount of human errors

What’s the Difference Between Continuous Delivery and Continuous Deployment?

Continuous delivery and continuous deployment are closely related concepts, indicating two levels of automation in a software development strategy.

Continuous Delivery vs. Continuous Deployment

Continuous delivery emphasizes automation that minimizes the manual effort required to deploy code changes. In a continuous delivery pipeline, developers create their code, it passes automated tests, and is then automatically integrated with a repository like a container registry or a binary repository. The operations teams can then deploy the code to the live production environment at the push of a button. 

Continuous deployment emphasizes reducing the burden on operations teams to accelerate the application delivery process, expanding continuous delivery automation into the next SDLC stage. It typically includes automation of additional steps in releasing new software to minimize the manual processes required. For example, a continuous deployment pipeline may automatically release the development team’s changes from the repository to the production environment, where customers can use it. Continuous deployment is harder to achieve than Continuous Delivery as it automatically sends approved artifacts to production environments without any manual intervention.

What Is the Continuous Delivery Pipeline?

The continuous delivery pipeline has five primary phases:

  1. Develop—a developer writes code with new or updated software functionality.
  2. Commit—the developer commits the code to a version control system.
  3. Test—the change undergoes multiple automated tests.
  4. Stage—the change is deployed to a realistic environment for final testing.
  5. Deploy—the change is deployed to a production environment.

The main identifying criterion of a true CD pipeline is that software can be deployed throughout its entire lifecycle. Any change to the software can be deployed to a testing or staging environment at the click of a button. Development teams receive fast feedback from automated tests, staging environments, and production environments, and can use this feedback to drive additional improvements.

Adopting GitOps for Continuous Delivery

The primary way to put GitOps into practice is pull-based deployment. In a traditional CI/CD pipeline, new code pushed to the application repository triggers deployment—in other words, it relies on an external event to trigger an action. By contrast, the pull-based method updates the application by frequently comparing the actual state of live infrastructure to the desired state specified in the environment repository. In Kubernetes, this is achieved by a GitOps controller that detects a discrepancy between the actual and desired states. Upon any discrepancy, it updates the infrastructure to match the environment repository. It might also check the image registry for new image versions to deploy.

Pull based deployment can thus reverse any change to the infrastructure that is not documented in the environment repository, maintaining the traceability of all changes in the Git log and preventing direct cluster changes that may cause state deviations.

Comments

Post a Comment

Popular posts from this blog

Different Types of Reports in Scrum - Agile

Image
  Introduction to Agile Reporting I’m not going to elaborate on the Agile Framework itself here.  1. Sprint Burndown At a Sprint-level, the burndown presents the  easiest way to track and report status  (the proverbial  Red / Amber / Green ), i.e., whether your Sprint is on or off-track, and what are the chances of meeting the Sprint goals. The burndown chart – when used right – can provide  near-real time updates  on Sprint progress. “If your team do it right, then they would take in just the right amount of work into a sprint.” At the beginning of a Sprint, the Scrum team perform Sprint Planning and agree to take on development work worth a certain number of Story points. This forms the basis for the Sprint Burndown chart. The total story points agreed at the beginning of the sprint make up the y-axis, and the individual dates in the Sprint make up x-axis. If your team do it right, then they would take in just the right amount of work into ...
Read more

Terraform

Image
  Terraform is an infrastructure as code tool that lets you build, change, and version cloud and on-prem resources safely and efficiently. HashiCorp Terraform is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to provision and manage all of your infrastructure throughout its lifecycle. Terraform can manage low-level components like compute, storage, and networking resources, as well as high-level components like DNS entries and SaaS features. How does Terraform work? Terraform creates and manages resources on cloud platforms and other services through their application programming interfaces (APIs). Providers enable Terraform to work with virtually any platform or service with an accessible API. HashiCorp and the Terraform community have already written  thousands of providers  to manage many different types of resources...
Read more

Scrum Master Interview help - Bootcamp

Understanding the MoSCoW prioritization | How to implement it into your project Projects, irrespective of their size or complexity, often juggle numerous tasks and requirements. In such a scenario,  MoSCoW prioritization  becomes essential to ensure the successful completion of the project.  Besides, it is also a very effective way to manage project priorities. With a straightforward and adaptable approach, the MoSCoW method helps manage stakeholder expectations and improve project outcomes. What is the MoSCoW prioritization technique?  The MoSCoW method is a prioritization matrix widely used in project management and software development. The term MoSCoW is an acronym that stands for  Must have ,  Should have ,  Could have , and  Won’t have , each denoting a level of priority. Here is the breakdown of the MoSCoW method:  Must have:  These are critical requirements that the project cannot be completed withou...
Read more