What Is Continuous Delivery and How Does It Work? | Synopsys
Table of contents

Definition

Continuous delivery (CD) is an approach to software engineering based on producing software in short cycles. By developing in short cycles, teams can reliably release their software at any time. With CD, development teams can build, test, and release software faster and more frequently. As a result, they can reduce the cost, time, and risk of delivering each change. A repeatable deployment process is important for continuous delivery. In continuous delivery, which can be looked at as an extension of continuous integration, “developers frequently hand off new code to the quality assurance (QA) and operations teams for testing,” as described by TechTarget. Continuous delivery is the second part of continuous integration / continuous delivery, or CI/CD, a practice that enables application development teams to release incremental code changes to production quickly and regularly.

<p>This eBook details three ways of achieving security with speed. </p>
<ul>
<li>Run the right test at the right time and to the right depth</li>
<li>Align remediation efforts with business risks</li>
<li>Empower developers to secure code as fast as they write it  </li>
</ul>

The Top Three Ways to Build Security into DevOps

This eBook details three ways of achieving security with speed. 

  • Run the right test at the right time and to the right depth
  • Align remediation efforts with business risks
  • Empower developers to secure code as fast as they write it  

What is continuous delivery in DevOps?

AWS notes that continuous delivery is a DevOps software development practice where “code changes are automatically built, tested, and prepared for a release to production. Continuous delivery expands upon continuous integration by deploying all code changes to a testing environment and/or a production environment after the build stage.”



How to secure continuous delivery?

The same tools that automate CI/CD can also be used to automate security. Colin Campbell, director of patterns and practices at Chef, relates this story: “A major financial organization immediately saw the benefits of using Chef’s automation platform when Shellshock hit in 2014. The company had migrated 2,200 servers to Chef, and it took those 2,200 servers 10 minutes to self-report the vulnerability and to self-patch. The company’s 66,000 servers that they hadn’t migrated to Chef? It took eight hours to identify the vulnerability, five days to patch all the servers, and a team of 18 to solve the problem.”


Continue reading