What Exactly is a Release Candidate (RC) in Software Development?
A Release Candidate (RC) is a production-ready software build that has completed all primary development and testing cycles, awaiting only final operational or business validation. It is not a draft for new features. An RC represents a potential shippable increment, meaning it is structurally safe to push to your live production environment right now if necessary.
As an Agile Coach, I sit in a lot of release planning meetings. The most terrifying phrase I hear isn’t about database migrations or server downtime. It is this: “We will just squeeze that feature into the Release Candidate.”
That single statement guarantees a chaotic deployment. Too many teams treat the RC phase as an informal extension of the development cycle. They assume the word “Candidate” means the business might still change its mind. In reality, “Candidate” means this specific artifact is applying for the job of Production Build. If it fails final inspection, you do not tweak it on the fly. You reject it, fix the root cause in your main development branch, and cut an entirely new candidate.
The Dangerous Trap of the “Work-In-Progress” Release Candidate
Why do engineering teams fall into the trap of continuously modifying an RC? They modify Release Candidates primarily because of stakeholder pressure to hit arbitrary delivery dates with incomplete features. Rather than delaying the release or shipping without the feature, the team compromises by tagging an RC and attempting to “fix it forward” while QA is actively testing.
This destroys the structural integrity of your software delivery pipeline.
When you inject new code into a frozen build, you instantly invalidate every automated and manual test run up to that precise moment. Regression testing devolves into a guessing game. Bugs multiply silently in the background. What was scheduled as a predictable, two-hour maintenance window extends into a frantic, high-stress weekend firefighting session.
If your team is still pushing new code for a feature inside an RC, you simply do not have a Release Candidate. You have a Work-In-Progress (WIP) with a highly dangerous label attached to it. You have stopped managing a software release and started managing a crisis.
How High-Performing Agile Teams Master the RC Phase
How do high-performing Agile and DevOps teams manage Release Candidates? Top-tier engineering organizations enforce strict boundaries, mandatory feature freezes, and unyielding adherence to the Definition of Done. They prioritize system stability over last-minute scope additions.
Top-tier engineering organizations do not rely on luck for smooth deployments. They rely on discipline. Here is how mature agile teams operate during the final release phase.
1. The Absolute Feature Freeze
Once a build is tagged as an RC, the scope is strictly locked. The only permitted code changes are critical, high-severity bug fixes that actively block the release. If a developer finishes a new feature while the RC is out for final validation, that feature belongs in the subsequent release pipeline. It never gets cherry-picked into the current RC.
Enforcing this boundary requires a strong Scrum Master, Delivery Lead, or Product Owner who is willing to shield the development team from late-stage stakeholder scope creep. The conversation is simple and factual: “We can add this feature today, but it requires cutting a new RC and restarting the full regression cycle, delaying the launch by 48 hours. Do you want to proceed?” When forced to weigh immediate gratification against a guaranteed delivery delay, stakeholders usually decline the late addition.
2. Strict Adherence to the Definition of Done (DoD)
An RC must completely satisfy your team’s established Definition of Done (DoD). It represents a truly potential shippable increment, not an IOU to finish critical validation steps later.
If your DoD states that all code must be peer-reviewed, achieve 90% unit test coverage, and clear static security scanning, the RC cannot bypass these steps. Teams frequently attempt to take dangerous shortcuts to hit marketing-driven release dates. A common excuse is, “We will finish the load testing in the staging environment after the RC is cut.” This entirely defeats the purpose of the candidate. The RC must prove it is ready for production under its own power, without carrying technical debt.
3. Value Protection Over Value Creation
During active sprint development, the team’s primary objective is value creation. You are building capabilities to solve user pain points. The exact moment an RC is cut, that objective flips 180 degrees. The new goal is value protection.
You shift from building new things to aggressively protecting system stability. Performance testing, security vulnerability scans, and final edge-case verification take center stage. You are actively hunting for reasons not to release this specific build. You want to break it in staging so it ultimately survives the brutal reality of production traffic. If engineers are still writing feature code for this build, they are directly distracted from the critical job of protecting the end-user experience.
4. Predictability for Leadership and Business
An RC provides Technical Leaders and Product Owners with high confidence. It serves as the vital bridge between engineering output and actual market delivery.
Business leaders require predictability to operate effectively. They need to coordinate marketing campaigns, align customer success teams, draft release notes, and update public documentation. When an RC is treated as a mutable, constantly changing draft, that business predictability vanishes. Strict RC discipline aligns your engineering rhythm directly with the broader business strategy.
How to Enforce Release Discipline Without Killing Team Morale
How do you actually stop stakeholders and engineers from tampering with a Release Candidate? You protect the RC by combining automated CI/CD safeguards with transparent, risk-based communication strategies.
You understand the theory, but executing it requires practical application. Here are field-tested methods to protect your release cycle:
- Automate the Boundaries: Do not rely on human willpower to enforce a feature freeze. Utilize your CI/CD pipeline. Configure repository branch protections so that once a release branch is cut, direct pushes are technically blocked. Require multi-party approval from a release manager or lead engineer for any pull request targeting the release branch. Make it physically difficult to bypass the established freeze.
- Reframe the Conversation Around Risk: When a Product Owner asks for a late addition, do not just say “No, that violates Agile principles.” That makes you sound like a dogmatic process cop. Instead, frame the conversation around risk and trade-offs. Explain that injecting the feature introduces a known risk of regression, which could break the core payment flow. By quantifying the risk, you force stakeholders to make a rational business decision rather than an emotional demand.
- Shorten the Release Cycles: The primary reason stakeholders panic and try to cram features into an RC is the fear of missing the release train. If your organization only ships to production once a quarter, missing a release is a massive penalty. The feature will languish for another three months. If you release every two weeks—or practice continuous deployment—the pressure instantly evaporates. Fast, reliable CI/CD pipelines are the ultimate cure for RC scope creep.
Handling the “Emergency Fix” During an RC Phase
How should a team handle critical bugs discovered inside an RC? High-performing teams follow a strict triage process: assess severity, fix the issue in the main branch first, and cut an entirely new Release Candidate version.
It happens to the best engineering teams. The RC is cut, final testing is underway, and a critical bug is discovered. High-performing teams follow a precise triage sequence for this exact scenario:
- Assess the Severity: Is this a true production blocker? If it is a minor cosmetic UI alignment issue, log it in the backlog for the next sprint. If it prevents a user from logging in or completing a transaction, it demands immediate action.
- Fix in Main, Cherry-Pick to Release: The developer writes the fix against the main development branch first. Once validated and merged there, the specific commit is carefully cherry-picked into the release branch. This strict workflow ensures the main branch always reflects reality and prevents the exact same bug from reappearing in the next sprint.
- Cut a New Candidate: You do not simply update the current RC. You tag a completely new version (for example, moving from v1.4.0-rc1 to v1.4.0-rc2). The testing cycle resets for the impacted application areas.
This unwavering discipline prevents the release branch from devolving into an isolated, untested, mutant version of your core codebase.
Why “Boring” Releases are the Ultimate Victory
Why are boring software releases considered successful? A boring release proves that your automated testing works, your Definition of Done is effective, and your team prioritizes stability over chaos.
In the world of software delivery, excitement is your absolute enemy. You want excitement in your product strategy. You want excitement in your user feedback. You absolutely do not want excitement during a live production deployment.
When you treat Release Candidates with genuine engineering discipline, deployment days become calm, predictable, and entirely non-eventful. The team clicks a button, traffic seamlessly routes to the new build, and everyone goes to lunch without checking their pagers. Predictability builds deep, unshakable trust between the engineering department and the wider business.
Stop treating your Release Candidate like a sandbox. Lock the scope, protect the application’s stability, and start shipping software with absolute confidence.