What is release automation? From deploy pipelines to automated releases

Many teams automate deployment but leave the release itself manual, which keeps half the process dependent on people remembering steps. That means you find out about bugs in your code the same way as your customers, after it’s impacted your broader user base.

Release automation closes that gap by controlling what happens after deploy: who sees a change, how far it rolls out, and when it rolls back.

What is release automation?

Release automation, sometimes referred to as application release automation (ARA), moves software changes from packaging and testing to production users without manual steps. It has two meanings:

1. Enterprise ARA. Packaging an application and carrying it from development to production through each environment. Enterprise ARA has three required parts: deployment automation, environment management and modeling, and release coordination.
2. Developer release automation. For a team shipping a library or service, it means scripting the release chores: bump the version, generate the changelog, tag the build, publish the artifact.

In both cases, the automation ends when code reaches production. However, reaching production is only half the journey, and it doesn’t cover who sees the change once it's live or what happens when it misbehaves.

Deployment automation: One build, every environment

Build the artifact once, then promote the same artifact through dev, staging, and production. There are no per-environment rebuilds or hand-run steps. If staging tests build a41f9c2, that means production gets a41f9c2 (byte for byte).

You don’t want your promotions to depend on someone’s memory. Eventually, that’ll fail, and someone will miss something. Learn all about how deployment automation works to see how it can help your organization release new features faster and more frequently.

Environment management: Keeping dev, staging, and prod in step

Automated promotion only works when the environments match. Config drift is how a release passes every check in staging but fails in production.

For example, staging load tests passed with 50 database connections. Production only has 10, though, because someone manually lowered it during an incident last year but never wrote it down. The new release works perfectly in staging but runs out of connections at peak traffic. And nothing in your pipeline could have caught that.

That’s why we recommend you treat environment config like code:

1. Keep it in version control.
2. Apply it through the pipeline.
3. Fail the build when two environments differ in undeclared ways.

Release coordination: Approvals, audit trails, and governance

Automation doesn’t mean there’s no sign-off. Auditors still need to see who approved what (and when). Instead, automation turns approval into a pipeline gate. It writes the audit record as part of the process instead of relying on you to assemble everything by hand later.

Some vendors call this layer release orchestration: coordinating approvals, schedules, and dependencies across teams and services so a multi-part release ships in the right order.

In LaunchDarkly, release pipelines (in beta for certain Enterprise customers as of October 2026) put approvals and rollout steps into one standardized path, so boolean flags in a pipeline move through the same phases and environments.

A release team at a Fortune 100 health insurer used to collect approvals through document templates, email chains, and copy-paste across several systems. Approvals often took longer than writing the code. The team automated about 95% of that workflow into a single auditable record, and uses LaunchDarkly to decide when deployed code becomes visible to members. The result:

• 3.91% change failure rate
• 3-to-5-minute approval-to-deployment time (down from several days)
• 150-200 releases per month from the same two-person team (up from 60-80)

Where does release automation fit in a CI/CD pipeline?

Release automation starts where continuous integration ends: once the build and tests pass. CI hands over a verified artifact. Release automation then:

• Versions the artifact
• Publishes the artifact
• Promotes through each environment
• Exposes to users

How does release automation differ from CI/CD?

CI/CD covers the entire pipeline. Release automation is the back half of it, and it also controls who sees the change after the deployment. Continuous deployment is the end state, where every passing change reaches production automatically.

Learn more about the front half of the pipeline with our CI/CD best practices and how DevOps and CI/CD relate guides.

How release automation pipelines work

Release automation pipelines include four steps that happen between a merged change and deployed code:

1. Tests pass: This is the gate. If the build is red, the pipeline stops.
2. Version calculated: Commit messages that follow a convention tell the pipeline whether this is a patch, minor, or major bump. See release versioning best practices for choosing a scheme.
3. Changelog generated: Sort similar commit messages into release notes, grouped by type, like Features or Fixes.
4. Artifact published: The build gets the new version tag and goes to your registry, where the deployment stage picks it up.

Steps 2 and 3 make automated release notes possible. When you structure your commits in a consistent format, the pipeline can read them to set the version and write the notes without anyone drafting by hand.

World Kinect, a global energy management company, used to run a manual deployment process built on config files, database-driven flags, and about six separate in-house flagging tools. After standardizing on one feature flag platform and moving to trunk-based development, the team:

• Migrated users off a legacy application with zero downtime to users
• Kept the blast radius under 1%
• Now ships about 640 releases a month (a 400% increase)

Deploying code isn’t the same as releasing

Deploying pushes new code onto production infrastructure, but a release exposes that code to your users. If you run them together as one event, every deployment risks itself on 100% of your traffic. Separating the two events lets you choose how much of your traffic each change reaches.

Deploying takes minutes, and releasing to everyone should be a decision you can undo. Decoupling deployment from release lets you control exposure:

1. Blue-green deployments keep two identical environments and switch traffic from old to new. Rollback is fast, but exposure is still all or nothing.
2. Canary releases send a small share of traffic to the new version first. Exposure is gradual, but it's controlled per build, so one bad feature holds back everything else in that build.
3. Feature flags ship both code paths in the same deploy and decide at runtime who gets which. Exposure is controlled per feature and per audience, and you can reverse it without a redeploy.

A flag starts as a manual switch, but you can add the automation layer to operate it for you. Automation advances the rollout as release conditions are met, compares the new code path’s performance, scales if the numbers hold, or rolls back if the metrics regress.

In LaunchDarkly, this is a guarded rollout, available on Enterprise plans with the Guardian add-on. Traffic to the new variation increases in stages while LaunchDarkly compares its metrics against the original variation. If it detects a regression, it notifies you or rolls the change back automatically (depending on how you've configured it). This is also known as progressive delivery.

Relativity, which builds software for legal teams, moved from a homegrown flag tool to LaunchDarkly during a front-end migration. Engineers had been meticulously watching release metrics themselves and making manual changes. Now, LaunchDarkly measures each rollout as it happens and can stop it automatically when guardrail metrics regress.

How AI is changing release automation

Teams increasingly can’t keep up with how fast AI coding assistants and agents write, test, and merge changes. At that volume, reviewing every change by hand gets harder. And teams feel it. The LaunchDarkly 2026 AI Control Gap Report found 94% of survey respondents report faster velocity, yet 91% are more cautious about deploying to production.

Caution doesn’t translate to stability, though. According to the 2026 LaunchDarkly AI Control Gap Report, 99% of survey respondents have runtime guardrails or safety mechanisms in place, but 69% still roll back or perform hotfixes on a weekly basis. And this isn’t an isolated finding. The 2025 DORA report found that “AI adoption now improves software delivery throughput, a key shift from last year. However, it still increases delivery instability.” That’s usually because guardrails aren’t integrated or standardized:

• Flags used inconsistently across services
• Rollouts coordinated manually
• Dashboards with regression charts but no linked changes

Release automation has to account for AI-built changes by incorporating the following:

1. Set guardrails before release: Tie each change to system and business metrics, and define thresholds for errors, latency, or user impact up front.
2. Roll back automatically: When a threshold is crossed, the rollout pauses or reverts with no redeploy.
3. Self-heal: Self-healing systems use guardrails you can configure to contain and correct the problem first, then tell the on-call engineer what happened.

This is what CodeControl does in LaunchDarkly. It helps teams ship AI-built code with confidence when your models are the authors and your reviewers are vastly outnumbered. Read more about runtime control for AI-generated code.

Release automation vs. release management

Release management describes the process and ownership, while release automation is the software that carries it out.

The release management process can be distilled into four stages:

1. Plan
2. Build
3. Test
4. Deploy

You can learn more about the process in our guide to release management, and this roundup of release management tools covers the tooling.

What are the benefits of release automation?

Teams that automate releases typically see lower change failure rates, faster recovery, a smaller impact area, and more frequent deployments:

• Lower change failure rate. Fewer deployments need a hotfix or rollback, because automation reduces config drift, skipped steps, and untested promotion paths.
• Faster failed deployment recovery time. This is a core DORA metric. When a release goes wrong, recovery can be a flag change or an automatic rollback, with no rebuild or redeploy. Rebuilds and redeploys usually take longer, because the pipeline has to run again.
• Smaller impact area. A regression caught at 1% of traffic can be rolled back before it reaches the rest of your users.
• Higher deployment frequency. Teams ship more often when shipping feels less risky.

Climate LLC (the digital farming arm of Bayer Crop Science) makes a cab app that farmers run during planting and harvest. An outage in those windows can mean lost or inaccurate field data. With releases behind flags, the team can return the app to a known safe state in real time when something breaks mid-season. Now, rolling back is a flag change instead of a redeploy.

Automate the release (not just the deploy) with LaunchDarkly

Deployment automation gets your code to production, but automating the release is how you close the AI control gap, and few have actually done it yet. The 2026 LaunchDarkly AI Control Gap Report found that only 15% of respondents deploy daily or more while keeping incidents to monthly or less. The way to join them is to plan for runtime control from the start: target changes to specific audiences, roll out in stages, and tie production monitoring to the feature that changed, so a metric spike points to the change that likely caused it.

Automating your releases doesn’t have to be a big daunting sprint. Instead, start by picking just one upcoming change:

1. Put it behind a flag so the deploy and the release are separate events.
2. Choose two guardrail metrics you already collect (such as error rate and p95 latency).
3. Roll it out in stages with automatic rollback turned on.

After you see it work, make that the default path for every change, including the ones AI agents write.

Download the 2026 LaunchDarkly AI Control Gap Report to see what high-performing teams do differently.