The most popular and comprehensive Open Source ECM platform
You may have heard the terms continuous delivery and continuous deployment.
What’s the difference these and how are they being used today?
Continuous delivery is the use of very short cycles during software development. It’s the philosophy for a software development process that is very lean and agile. It requires that much or all of the build, test and release processes be automated to ensure consistency and that the iterations of the development cycle are completed quickly. With continuous delivery, at any point in time, a reliable and feature up-to-date version of the software can be released. Because the time difference between releases is short, the differences between the new release and the previous release are small, which usually implies that the risk for pushing out a new release is also small.
Continuous deployment takes continuous delivery one step further. With continuous deployment, the goal is to minimize the time from when the code is written to the time when it is actually deployed and used by live users in production. Mike Mooney defined continuous deployment as “consistently deploying code to production as features are completed, and as soon as you have met the release criteria for those features.” This approach is better suited for systems built from independent services, and it probably makes the most sense within a cloud environment. For example, with the approach, an individual service can be updated and swapped out and then the consequences can be monitored with the ability to quickly roll back the change if something goes awry. Some well-known cloud-based applications are using continuous deployment, including Etsy, Facebook and Flickr.
A new book and recent article in O’Reilly Radar by Jim Bird discuss the two approaches to software development and deployment. Bird looks at the two development approaches in the context of the financial industry.
Bird writes that “while organizations like Etsy and Wealthfront work hard to make Continuous Deployment safe, it is scary to auditors, to operations managers, and to CTOs like me who have been working in financial technology and understand the risks involved in making changes to a live, business-critical system. Continuous Deployment requires you to shut down a running application on a server or a virtual machine, load new code, and restart. This isn’t that much of a concern for stateless web applications with pooled connections, where browser users aren’t likely to notice that they’ve been switched to a new environment in Blue-Green deployment… deploying changes continuously during the day at a stock exchange connected to hundreds of financial firms submitting thousands of orders every second and where response times are measured in microseconds isn’t practical. Dropping a stateful FIX session with a trading counterparty and reconnecting, or introducing any kind of temporary slowdown, will cause high-speed algorithmic trading engines to panic.”