We can reduce the risk of things going wrong during release by releasing more often. For this, automating the whole release process (including package release, infrastructure settings, deploy, and final sanity tests) is the only solution. We need to eliminate as many manual steps as we can to increase the release frequency. This phase is continu0us delivery (CD). Its definition by Wikipedia is as follows:
Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.
CD is a software strategy that enables any organization to deliver new features to users as fast and as efficiently as possible. The core idea of CD is to create a repeatable, reliable, and incrementally improving process for taking software from developers to real-time customers. We achieve CD by ensuring that code is always in a deployable state, even when thousands of developers are making changes on a daily basis. That's why, CI mostly goes along with CD. If any organization is broken on continuous integration, then it's nearly impossible for them to maintain CD.
The goal of CD is to enable a constant flow of changes into production via an automated software production line. The CD pipeline is what makes it all happen. The idea of having a frequent release sometimes comes with a picture of a less stable release. As a matter of fact, it's not the case. Studies show that the team that is delivering fast is mostly an efficient team and they always deliver good quality release. There are high chances that the team that is not able to deliver fast is not much efficient, which in turn impacts the quality of deliverables. CD is not magic. It's about continuous, daily improvement and discipline of achieving higher performance.
The preceding diagram gives an idea about CD. The image is self-explanatory. Developers build the feature, deploy it to staging , test it, and release it. Transformation between tests and release is a manual process in CD. After testing is done, the QA team normally checks the test results, and then, after satisfaction, they release them to production. So, manual acceptance is still there in CD. CD lets developers automate testing beyond just unit tests so that they can verify application updates across multiple dimensions before deploying to customers.
On the other side, if we make this step also automated, then it becomes another CD. The basic difference between both the CDs is shown in the following diagram:
There is one manual step in continuous delivery, which is recovered in CD. A more confident CD cycle is a good candidate of continuous deployment. It's the next step of continuous delivery. The only way to achieve any CD, continuous delivery or continuous deployment, is automation. Auto-build trigger on code commit, Automation testing, frequent deployment, and so on; are the steps required for CD. Continuous deployment is every technical organization's ultimate goal, but business also has to be ready for it. To wrap up the stuff here, by defining CI and CD practices, and understanding the areas and benefits of both, teams can create, prioritize, and complete tasks in a more efficient and fast manner.