This content originally appeared on DEV Community and was authored by Edward Allen Mercado
In DevOps methodologies, Continuous Delivery and Continuous Deployment are vague terms that we mostly took for granted and often compared as similar.
Let's discuss first about the well known term in DevOps called the CICD - Continuous Integration and Continuous Delivery/Deployment.
What is Continuous Integration and Continuous Delivery/Deployment?
This is considered as one of the best practices for DevOps teams to implement. This is a method to frequently deliver applications to customers by introducing automation into the stages of application development.
It also integrates with the Agile Methodology best practice as it will enable developers to focus on providing code quality, and meet business requirements.
Now, let's break down these terms into chunks.
Continuous Integration
Continuous Integration (CI) is a practice where developers frequently merge the changes to the main repository (such as Github, AWS CodeCommit, etc.), after which automated builds and tests are run.
CI most often refers to the build or integration stage of application development. Successful CI means new code changes to an app are regularly built, tested, and merged to a shared repository.
Continuous Delivery and Deployment
When the code changes have been built, tested. Continuous Delivery and Deployment (CD) stage will prepare the changes for production release. In simple terms it is an extension of the Continuous Integration stage by deploying all code changes to a testing environment, a production environment, or both after the build stage has been completed.
Continuous Delivery is not Continuous Deployment
Continuous Delivery
We tend to misinterpret Continuous Delivery as after the code has been built, tested in Continuous Integration stage is that every change will immediately be applied to the destination environment such as QA, PROD, etc. but it is not.
The point of Continuous Delivery is to ensure that every change is ready to deploy to the destination environment which involves reviews or manual integrations from non-technical team members to control the process.
Benefits of Continuous Delivery
Enabling a non-technical team as part of the process reduces the burden on the development team so they may continue to execute subsequent application improvements.
Continuous Deployment
On the other hand, Continuous Deployment is an improved version of the Continuous Delivery where all of the changes are ready to deploy to the destination environment without the manual integration, this process is completely automated, and only failed verification step will prevent pushing the changes to the environment.
You can achieve Continuous Deployment when your pipeline is mature enough where the involved teams are confident in the applied automation inside your pipeline.
Benefits of Continuous Deployment
With all of the stages automated, it means that the developer's change could go live within minutes of writing it, you can deliver to customers quicker and start to do iterations base on their feedbacks. It's easier to release changes to apps in small pieces, rather than all at once.
Building a pipeline base on your business needs could be difficult, having these terms clear can help the planning much easier.
Remember that DevOps is a journey, not the destination. Feedback to the pipeline is continuously collected and metrics are still needed to be in place to monitor the critical parts of the pipeline.
Hey! You can reach me at:
This content originally appeared on DEV Community and was authored by Edward Allen Mercado
![](https://www.radiofree.org/wp-content/plugins/print-app/icon.jpg)
Edward Allen Mercado | Sciencx (2021-10-07T06:56:32+00:00) Continuous Delivery is NOT Continuous Deployment. Retrieved from https://www.scien.cx/2021/10/07/continuous-delivery-is-not-continuous-deployment/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.