Continuous Delivery - Revision history

User: The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

2021-02-06T14:51:36Z

The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

User at 19:20, 15 January 2021

2021-01-15T19:20:48Z

User: Created page with "'''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 t..."

2021-01-15T18:44:08Z

Created page with "'''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 t..."

New page

'''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 and, when releasing the software, doing so manually. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.<ref>Definition - What is Continuoue Delivery? [https://en.wikipedia.org/wiki/Continuous_delivery Wikipedia]</ref>

'''Continuous Delivery vs. Continuous Deployment<ref>Continuous Delivery vs. Continuous Deployment [https://aws.amazon.com/devops/continuous-delivery/ AWS]</ref>'''<br />
With continuous delivery, every code change is built, tested, and then pushed to a non-production testing or staging environment. There can be multiple, parallel test stages before a production deployment. The difference between continuous delivery and continuous deployment is the presence of a manual approval to update to production. With continuous deployment, production happens automatically without explicit approval.

[[File:Continuous Delivery vs Continuous Deployment.png|1000px|Continuous Delivery vs Continuous Deployment]]<br />
source: AWS

Continuous delivery automates the entire software release process. Every revision that is committed triggers an automated flow that builds, tests, and then stages the update. The final decision to deploy to a live production environment is triggered by the developer.

'''References'''
<references/>

@@ Line 1: / Line 1: @@
-'''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 and, when releasing the software, doing so manually. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.<ref>Definition - What is Continuoue Delivery? [https://en.wikipedia.org/wiki/Continuous_delivery Wikipedia]</ref>
+'''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 and, when releasing the software, doing so manually. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and [[risk]] of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment [[process]] is important for continuous delivery.<ref>Definition - What is Continuoue Delivery? [https://en.wikipedia.org/wiki/Continuous_delivery Wikipedia]</ref>
@@ Line 17: / Line 17: @@
 *Reduced Deployment Risk: since you are deploying smaller changes, there's less to go wrong and it's easier to fix should a problem appear.
 *Believable Progress: many folks track progress by tracking work done. If "done" means "developers declare it to be done" that's much less believable than if it's deployed into a production (or production-like) environment.
-*User Feedback: the biggest risk to any software effort is that you end up building something that isn't useful. The earlier and more frequently you get working software in front of real users, the quicker you get feedback to find out how valuable it really is
+*User [[Feedback]]: the biggest risk to any software effort is that you end up building something that isn't useful. The earlier and more frequently you get working software in front of real users, the quicker you get feedback to find out how valuable it really is
 '''References'''
 <references/>