Continuous Delivery (CD) in software development
Continuous Delivery describes the continuous deployment of changes to an application on a server that the customer cannot access (mostly a staging environment). Through the continuous deployment the test team can always check the latest version of the software.
As Continuous Integration is the basis for Continuous Delivery, attention should be paid to an already well-functioning CI pipeline.
Differentiation between Continuous Delivery and Continuous Deployment
In difference to Continuous Deployment, Continuous Delivery does not deliver each change to the customer automatically. Each change gets deployed on an internal server and can be tested there manually. That means that the degree of automation of Continuous Delivery is lower than Continuous Deployment.
In academic terms, the difference lies in the degree of automation in relation to the deployment method (Continuous Deployment: automatic, Continuous Delivery: manual). In practice, however, it can happen that these terms are used almost synonymously.
The term Continuous Deployment first appeared in 2009 in a blog post by Timothy Fitz. About a year later, the first work on continuous delivery was published - the book "Continuous Delivery: Reliable Software Releases Through Build, Test and Deployment Automation" by Jez Humble and David Farley. The two authors deliberately decided against the term Continuous Deployment, as Continuous Delivery does not automatically deploy to production. Continuous deployment implies continuous delivery. However, this is not the case the other way around.
Compared to Continuous Integration, the automation is higher, because the latest version is always ready to be tested. In Continuous Integration that is not the case.
Continuous Delivery with the Cloudogu EcoSystem
To implement a Continuous Delivery pipeline with the Cloudogu EcoSystem you only have to provide a deployment target for Jenkins.