The New Software Release Lifecycle: Releasing, Measuring, and Iterating on Software in Production With LaunchDarkly

Separating "deploy" from "release"

In the classic DevOps ‘infinity loop’ diagram, you’ll notice that ‘release’ comes before ‘deploy’. ‘Release’, in this sense, refers to creating a stable branch of software that can later be deployed. It does not refer to connecting software to end users. At LaunchDarkly, we view deploy and release differently.

LaunchDarkly feature flags decouple deployments from releases. To deploy, in this sense, is to install a new software version on a given environment. To release is to make that software available to users in that environment. Thus, in our model, release follows deploy. This approach to releasing gives software development teams more control over how and when to deliver code to end users - opening up a lot of value on the right side of the DevOps infinity loop. 

In this blog post, we’ll explore the new software release lifecycle powered by feature management. We’ll explain how teams can methodically release, measure, and iterate on software in production.

Release

Embed best practices in your release process

Establishing and mapping software development best practices to user workflows is difficult. It’s one thing to map out best practices in a neat document in Confluence, but it’s another to ensure that your team has the systems to implement them on a day-to-day basis. With the introduction of Release Assistant, LaunchDarkly enables users to embed best practices into reusable release pipelines so every change can follow a successful path to production. Now you can move your flags across a pipeline designed to fit your best practices and with the confidence that LaunchDarkly will prompt you when phases are complete (Learn more about Release Assistant). 

And of course, as we’ll get to in the next section, if there’s an issue with a release, you can instantly roll back at any time without redeploying or impacting your customers.

How does it work in practice?

Let’s imagine a scenario for an online retailer’s engineering team, where each project starts in a development environment. After the engineer working on it has completed development of the feature or feature component, and confirms that things are working as expected, it’s turned on for all developers in the organization. 

After that, the new feature enters the formal test phase, where multiple teams, including our product managers and product designers, QA the feature in a test environment (in LaunchDarkly, you can also test in production instead of using a separate test environment) to uncover bugs and ensure that it passes our acceptance criteria. 

Once that’s complete, the testing phase can be marked as done, and the team can proceed to the GA phase, where the feature is released to a subset of our customers. In order to make sure that our team performs this progression in accordance with our internal and industry best practices, we can create a Release Pipeline to structure this process. And since the front-end team’s needs may differ from other teams in my company, we can create specific and reusable Release Pipelines for each of the teams.

Decide exactly whom to release to 

So now we have our release processes mapped out, with confidence that our developers have guidance in performing the next proper step. But which subset of customers should we release to? Using LaunchDarkly, you can release to anyone you want, based on anything you know about your audience. By targeting contexts, you can control who receives new features based on properties spanning their application, devices, systems, organization, and more. 

There are several instances where targeting can deliver value:

• Subscription tiers: Offering different features or entitlements to users based on their subscription level. 
• Personalization: Customizing the user experience on different user roles or preferences. 
• Compliance: Adapting features to align with local regulations or legal requirements. 
• Early access programs (EAP): Selectively exposing a new feature to consumers who have opted in, with the intention of collecting product feedback. 

How does it work in practice? 

In this case, the retailer will want to target based on subscription tier.The retailer has multiple tiers of users, and only ‘premier’-tier users are granted rewards points with their access. We can target users in the  premier-customers segment to make sure that they’re being exclusively presented with the new feature. And even though we’ve already tested this feature, we want to offset any potential negative impact of the release, so we’ll choose to release to only 10% of the premier-customers segment at first.We'll measure the impact of this release (as you’ll see in the next section), before releasing to the rest of my most valuable customers.

Measure

Understand the impact of your releases

Traditionally, the ‘monitor’ section of the DevOps infinity loop comprises several types of monitoring, including application performance monitoring (APM), infrastructure monitoring, and user feedback monitoring. LaunchDarkly can integrate with your APM tool of choice. 

But unfortunately, issues within a small rollout will often fail to trigger existing alerts, and the triggered alerts can be difficult to attribute to a feature flag change. With the recently introduced Release Guardian (join the waitlist for early access), LaunchDarkly gives you the ability to ensure that critical metrics are monitored on every release, with automatic alerts and roll-backs for changes that negatively affect metrics. Additionally, you can immediately identify the specific flag configuration change that caused the problem before it has the chance to degrade overall performance. 

How does it work in practice? 

Let’s apply this to the rewards module release for our online retailer. Since we want to track the impact of this release on the specific segment of users we’re targeting, we’ll use Release Guardian. We integrate our APM to send error events to LaunchDarkly. Then, we create an error metric based on the frequency of those events, and add that metric to the flag for the release of the rewards module. When we turn it on, we can monitor user contexts and metrics in real time so that I can automatically roll back if any errors are detected.

Measure product success with experimentation

Many teams hold off on incorporating experimentation into their work streams because of the idea that setting up valid experiments requires too much pre-existing expertise. But without experimentation it’s impossible to directly and accurately connect your product releases to business impact. When you’re able to measure 

With the introduction of out-of-the-box funnel experiments, software development teams now have an easy way to measure how changes to their main product funnels affect their business goals—like assessing the impact of a rewards-point module on our checkout completion rate. 

How does it work in practice? 

Thankfully, designing experiments is easy in LaunchDarkly. First, we’ll want to come up with a list of metrics to track to understand the efficacy of adding a rewards point module in the checkout flow - metrics like checkout conversion rate, rewards point usage, and # of repeat purchases. Then, we’ll connect those metrics to LaunchDarkly and set up an experiment with a hypothesis of something like ‘by introducing a reward points module in the checkout flow, users will decide to use rewards points on their purchases more often’. We’ll then choose our audience and sample size, and create and run the experiment. 

Iterate

Improve processes and velocity with engineering insights

Our online retailer has successfully released the new reward points module in the checkout flow—now what? We already discussed how teams can measure and iterate using experiments in LaunchDarkly. But from an engineering perspective, we can also iterate on the left-loop processes and performance from the DevOps infinity loop. Using the LaunchDarkly Engineering Insights Hub, we can use insights about the team’s performance to inform decision making. Specifically, it allows for the tracking of essential metrics like Deployment Frequency, Lead Time, and other feature-flag-specific insights—across all projects in one place.

How does it work in practice?

After the release of the new rewards module, we can take a look at our Engineering Insights Hub dashboard to see how each of my projects is performing. If, for example, we see a decrease in the value of the ‘Risk’ metric (which includes the deployment failure rate and flag change impact), we can use that decision to iterate on my testing and QA processes to ensure that more rigorous validation is happening before releasing. 

Connecting code to end users

If your engineering team is only focused on ‘release’ in the traditional DevOps infinity loop sense, and not on how best to connect your code to your end users, you can derive a lot of value by expanding your DevOps loop. Using LaunchDarkly, you can: 

• Release more efficiently by embedding best practices in your release processes
• Measure the impact of your releases via understanding release impact and through experimentation
• Iterate on your processes with engineering insights across your org

To learn more, sign up for a demo today.