Progressive delivery is a practice that builds on the capabilities of Continuous Integration (CI) and Continuous Delivery (CD) to help you deliver with control. Software delivery helps organizations and teams get their changes out to customers quickly. Often, what gets forgotten is discussing how we ensure quality and reduce the risks of introducing said changes to customers. Delivering changes rapidly can often be at odds with not breaking things. This blog post will share what you need to know about progressive delivery as we share the ways organizations are using it today.
Progressive delivery is a practice that allows organizations to control how and when new software features or changes are delivered. It builds on the capabilities and practices of feature flag management and deployment strategies like blue-green and canary deployments. Ultimately, progressive delivery combines software development and delivery practices allowing organizations to deliver with control.
When discussing the software development life cycle (SDLC), we often mention continuous integration (CI) and continuous delivery (CD), which captures the how, when, where, and why of our software delivery. CI/CD is integral to quickly, safely, and repeatably we can get our software changes to our users and customers. Progressive delivery leverages your CI/CD pipelines alongside our software development and delivery practices to boost our software delivery capabilities.
There are several key components to achieving progressive delivery.
Source code management is a practice that allows for the reverting, tracking, and correction of software code. A key element of progressive delivery includes application development code that is properly managed and tracked by a version control system like Git. In a basic Git-based workflow, you have the main branch from the main branch, which contains different versions of your application’s code, branch from specific versions of the application code when working on a different feature. This allows for development progress to continue without the fear of losing changes as developers work on the same codebase.
Having source management is a key element for progressive delivery as it serves as the foundation for feature development, testing, and rollout.
CI/CD is a shortened term for Continuous Integration and Continuous Delivery. CI/CD is the combination of principles, practices, and capabilities that allow for software changes of all kinds to get users in a quick, repeatable, and safe manner. This allows for software developers to integrate their feature or service changes continuously and for IT and operations teams to deliver with the standards, security, and confidence businesses need. CI/CD also serves as a foundation for your progressive delivery capabilities. Automated testing ensures that these integrations and deliveries maintain the desired quality.
You can learn more about CI/CD in this blog post.
As a development codebase grows, so often does the development team. With new feature requests, developers and innovation syncing and aligning to a development pace can be difficult, especially for complex feature work. There are many challenges that long-running feature work face when it comes to delivering fast. Merge conflicts arise for long-lived development branches, and often, features require manual testing. Feature flags, also known as feature toggles, control the visibility of features behind a logic (often Boolean) flag. This allows teams to avoid redeploying an application to enable a feature for testing or production.
Feature flag management also has many benefits to development workflows. Contributors to a codebase don’t have to wait for a feature to be fully finished to merge into the development or main branch. Developers can also test their features by controlling their feature flag and exposing their feature in a running application in a test or development environment.
A/B testing, also known as split testing, is a technique that involves exposing two variants of the same application service to different segments of users. By shifting specific over to different versions of an application, teams can compare, experiment, and better understand how these changes impact a specific set of users. To effectively conduct A/B testing, it's essential to know how to create a flag that can toggle between the two variants.
Also known as feature rollout, these deployment or release strategies are used to change or upgrade a running instance of an application. There are three kinds of deployment strategies, rolling deployments, blue-green deployments, and canary deployments. Of these three strategies, two are progressive since they involve progressively shifting user traffic to a running service.
The Blue-Green deployment is a deployment strategy that gradually transfers user traffic from a previous version(green) of an application or service to a new release(blue) of the application or service.
The Canary Deployment is a deployment strategy that releases an application or service to a subset of users.
Both blue-green and canary deployments limit the impact of application changes. These capabilities can be beneficial if deployments are risky and have severe consequences to the user base in breaking changes.
Observability leverages metrics, tracing, and logging capabilities to provide organizations and teams with answers to questions regarding their running services without the need to deliver another instance of the application or service to answer those questions. Understanding your services interact or perform can give developers a better understanding of what is breaking and what is performant. Often we need to understand an application's performance before we can achieve the confidence needed to release a change to an entire user base, and this is where observability matters.
The best approach to implementing progressive delivery is to build the key elements of progressive delivery incrementally. A common practice is to invest in your development workflows. This can involve introducing feature flag management capabilities through an SDK or by building it a home-grown solution. Some other organizations may need to introduce source code management practices first before even discussing A/B testing capabilities or feature flag management. If you’re starting with software development and would like to read more about git-based workflows and how development and feature branching works, take a look at this source-code management guide.
Some organizations use feature flag management within their development processes already but need more capabilities around verifying deployments. It may make sense to invest efforts into monitoring or observability solutions to measure and understand application services. You can’t compare or baseline performance without these capabilities. And changes go out with confidence, so this can often be the next step in your progressive delivery journey.
And lastly, there is a deployment aspect to progressive delivery. Your platforms should support deployment strategies like canary or blue-green deployments. Deployment capabilities can come from your continuous delivery platform or other solutions like a service mesh. If you’re looking for a complete solution to deploy your services to production safely, I recommend looking at Harness’s CI/CD platform.
Today software delivery isn’t just about speed. Progressive delivery joins software development and delivery practices to better support and control your software delivery. If you’re looking to move fast without breaking things and implementing any progressive delivery element quickly, I recommend trying Harness for free.
For more on progressive delivery, let's look at Feature Flags!
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.