Need for continuous delivery
Currently, the process of software development and release are on a fast-track approach from yearly to quarterly to monthly to fortnight releases based on the software development life cycle SDLC chosen, even there are cases of an on-demand release which can happen at any time based on the request of the client or the issue fix for production.
This fast-track approach cannot be achieved through a manual process, which may lead to delay in performing activities due to human error. This is where the CI/CD (continuous integration/continuous delivery/deployment) approach can accelerate the process of development to delivery/deployment through automated tools without/with minimal human intervention.
What does continuous delivery do?
Continuous delivery is an approach to control and automate the process of the software development life cycle. It involves monitoring change of code/artifacts in SCM to make the build ready for production deployment by performing various automated testing, such as integration testing, smoke testing, load testing, etc., in various environments like staging and UAT. The following image details the stages involved in the continuous delivery process.
If any of the stages in the process fail, then the build won’t be available for production. The deployment of the build into the production environment is a manual process with a single button click. This means all the steps in the process are automated except the deployment in the production environment, which needs manual approval. The manual deployment of production may look a little different, but the new code going live as soon as the pipelines are completed can be dangerous in some cases. In fact, one-click manual deployment does not take much time but avoids unwanted issues in a production environment, leading to unavailability of service or downtime.
Activities of continuous delivery can be designed with multiple pipelines and stages where each can perform defined operations. Also, the execution of the pipelines can be triggered in multiple ways, such as polling SCM for changes, manual, schedule, and by other pipeline/stages, etc. Failure handling is different for each application, and how to handle or what should happen on failure can be configured in particular stages. Multiple deployment strategies can be configured, such as blue-green deployment, canary deployment, rollbacks, roll forward, etc.
How do continuous delivery, continuous integration, and continuous deployment differ?
Continuous delivery is one step ahead of continuous integration and one step behind continuous deployment. The following image gives the brief difference between continuous integration/delivery/deployment.
Continuous integration forms the base for both continuous delivery and continuous deployment. It is a process of merging changes of multiple developers in a team and verifying the changes by creating a build. This helps in avoiding the integration challenges at the last minute of a release cycle. Continuous deployment performs operations similar to continuous delivery, but there are no manual interventions; all the stages are automated here.
Benefits of continuous delivery
- Process automation of software release – Takes code from a development environment to build qualified for production through automated pipelines
- Productivity improvement – Excludes manual tasks, reduces errors, and bugs to improve productivity
- Quick in identifying and fixing issues – Identifying bugs or issues in the build at earlier stages and enables to fix quickly
- Faster delivery – Does automated build, testing, and make production artifacts ready which can be deployed at anytime
- Reliable release – Reduces risk in the release process and makes only valid builds available for production deployment
Continuous delivery tools
There are several tools available in the market for continuous delivery. We have briefed two tools here:
GoCD
GoCD is an open-source continuous delivery tool with a server and agent concept, where the configuration and orchestration are performed in GoCD server UI, and the actual execution is performed in GoCD agents. The server is deployed in a centralized system, and agents are deployed in the actual environment where the operations must be performed. The agents register themselves with a server.
Pipelines, stages, jobs, and tasks are the concepts used in GoCD to create the strategy. When a pipeline gets triggered, an agent configured with the same environment and resource of the pipeline collects the details and starts executing. GoCD also supports Kubernetes-based deployments and elastic agents, which is a kind of on-demand agent in a cluster to perform the required operation.
Spinnaker
Spinnaker is another open-source, multi-cloud tool for continuous delivery designed by Netflix and enhanced by Google. It is primarily designed to work with a cloud environment. Spinnaker is more capable in cloud deployments and is supported by cloud providers such as AWS, AZURE, GCP, Oracle Cloud, and Kubernetes.
Spinnaker uses concepts such as applications, clusters, projects, pipelines, and stages to create the strategy. It is capable of designing the delivery with Blue-Green, Canary deployments strategies in clusters. It supports cross-cloud platforms to perform the required operations.
References
- Continuous delivery – Wikipedia
- What is Continuous Delivery? - Continuous Delivery Explained
- Continuous integration vs. continuous delivery vs. continuous deployment
- What Is Continuous Delivery? The Benefits and Best Practices
- GoCD - Free & Open Source CI/CD Server
- Spinnaker - Cloud Native Continuous Delivery
- Plagiarism Checker | 100% Free and Accurate - Duplichecker.com
