Posts filed under: Continuous Delivery

Continuous Delivery

This page contains posts by Jayme related to Continuous Delivery. This term was coined by Jez Humble of Thoughtworks. He referenced the first principle of the Agile Manifesto, which states:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Continuous delivery at its core is a set of patterns and practices that enable a company that builds software products and services to reduce their cycle time. Cycle time is a measurement of the time it takes from when someone has an idea, until it is delivered to customers.

The primary innovation of Continuous Delivery is the concept of a deployment pipeline. The deployment pipeline uses technology to automate the processes typically used to release software.

Continuous Delivery is closely related to the DevOps movement, in that developers and operations must typically work together closely to make it a reality. However, many companies today still have developers and operations working together but have not built a complete deployment pipeline. Conversely, many companies have built a deployment pipeline, but still keep development and operations reporting under separate departments.


Much like what is happening in the “big data” space, challenges with interoperability in the IT deployment tool market are converging to create an opportunity for standardization. Before I go any further, let me introduce two terms that have no official...
While a team must adopt a customer-guided, acceptance criteria-driven culture to begin releasing IT assets frequently and with high quality, eventually an investment needs to be made to create a Deployment Pipeline. Put simply, this is a technology that enables an organization...
Getting revenue generating IT released faster is a clear advantage. The biggest ROI of Continuous Delivery is a little more subtle....
Ahh, estimating. We all hate to do it, but it's critical when releasing more often. The good news is it's not nearly as important to get it "just right" for an entire effort, but it is important that the current...
Think back to the last time you released to your customers. There was probably a brief feeling of satisfaction, hopefully a validation from the customer that you delivered what they wanted, and your team learned a thing or two about...
When a team decides to try reducing the time it takes for their ideas to get to their customers (cycle time), there are a few new technical investments that must be made. However, without business stakeholders supporting the changes in a SCRUM approach...
If you want to release software faster, it’s a given that you need automated deployment capabilities, and an incremental product change process like SCRUM – but you also need confidence in the code base. This confidence comes from having agreement...
Most software applications leverage a variety of third party libraries, middleware products, and frameworks to work. Each of these tools typically comes with its own method of configuration. How you manage this configuration has an impact on your ability to...
Since I adjusted the focus of my subject matter on this blog over the past couple of weeks, one of the main subjects I’ve been talking about is continuous delivery. This is a term coined in a book by the...
If you are a developer that writes code (yes, some don’t), you’ve inevitably been boxed into the “refactoring justification corner”. At some point you realize that a task you’ve been assigned affects more than just the code you thought it...
I’m taking a break from my posts on continuous delivery to talk about a related trend that continues unabated. Ask yourself, have you ever heard any of these phrases uttered in your delivery process (or perhaps said them yourself)? “That...
>