Blue-Green Deployment
Two complete production environments, with traffic switched from one to the other — allowing an instant, full reversal if the new environment misbehaves.
Deployment & Enablement · Step 05 · How We Work
Release Is a Decision, Not an Event.
Development & Integration produces verified software — but verified software is not yet live software. This stage governs how, when, and how safely that software is exposed to real production traffic, and ensures the people responsible for operating it are ready before it arrives.
Deployment at OpenQCore is treated as a controlled exposure of risk, not a single irreversible moment. A release is not "done" when code reaches production. It is done when it has been exposed gradually, observed under real conditions, and confirmed safe — with a defined path back if it is not.
Not this question
"Is the code ready to ship?"
This question, instead
"How do we expose this change to real users in a way that limits the blast radius of anything we did not anticipate — and can we reverse it quickly if we need to?"
Progressive Delivery · Risk Containment · Reversibility · Readiness · Enablement
Why Deployment Follows Verification
Verified Is Not the Same as Proven in Production.
The previous stage confirms that a change satisfies its acceptance criteria under test. It does not confirm how that change behaves under real production load, real user behavior, or real interactions with systems that cannot be fully replicated in a test environment. Deployment & Enablement exists precisely because that gap is real — and because closing it safely requires its own discipline.
Ready for Deployment → Controlled Production Exposure
Why Deployment Discipline Matters
Speed Without Reversibility Is Not Progress.
The same DORA research introduced during Development & Integration — Forsgren, Humble and Kim's Accelerate (2018) — pairs its throughput metrics with two stability metrics that matter specifically at this stage.
Deployment Frequency
How often an organization successfully releases to production.
Forsgren, Humble & Kim, Accelerate (2018); DORA, State of DevOps research.
Time to Restore Service
How long it takes to recover when a deployment degrades production.
Forsgren, Humble & Kim, Accelerate (2018); DORA, State of DevOps research.
High-performing organizations, in this research, do not simply deploy often — they deploy in a way that keeps recovery time short when something goes wrong. OpenQCore treats these as a single objective, not a trade-off: the practices in this stage are designed to make deployment both frequent and quickly reversible.
Progressive Delivery Strategies
Separate the Decision to Release From the Decision to Deploy.
Practices formalized in Humble and Farley's influential Continuous Delivery (2010) distinguish deploying a change from releasing it to users — a distinction OpenQCore treats as a foundational design choice for how software reaches production.
Canary Releases
A new version is exposed to a small fraction of real traffic first, observed against defined signals, and only expanded once those signals hold.
Feature Flags
Code can be deployed to production while remaining inactive for users — separating the act of shipping code from the act of exposing a capability.
Deployment Environments & Promotion
A Change Earns Its Way to Production. It Is Not Sent There Directly.
A change moves through defined environments — development, staging, and production — with explicit verification at each promotion, not a single test pass followed by a direct release.
Development
Where a change is built and initially verified in isolation.
Staging
Where a change is verified against production-like conditions, configuration, and integrations.
Production
Where a change is exposed to real traffic — progressively, and under observation.
Rollback & Recovery Design
The Rollback Plan Is Written Before the Deployment, Not During the Incident.
A rollback strategy decided while a system is already degraded is a rollback strategy decided under pressure, with incomplete information, and often too late. OpenQCore defines the rollback path for a change before it is deployed — not after something goes wrong.
Defined Rollback Trigger Conditions
The specific signals that would trigger a rollback, agreed in advance rather than judged in the moment.
Data & State Compatibility
Explicit consideration of whether a rollback is safe given any data or schema changes the deployment introduced.
Recovery Time Objective
A stated target for how quickly service should be restored if a rollback is required.
Infrastructure as Code & Reproducibility
A Deployment That Cannot Be Repeated Exactly Cannot Be Trusted.
Deployment steps are defined as code — version-controlled, reviewed, and executed identically every time — rather than performed as manual actions dependent on an individual's memory of the correct sequence. This is a foundational practice in the same body of continuous delivery research referenced above: a deployment process that cannot be reproduced exactly cannot be verified, and cannot be safely automated.
Deployment Risk Assessment
Every Deployment Is Evaluated Before It Happens, Not After.
Consistent with the threat modeling introduced during Development & Integration, each deployment is assessed for its specific risk profile before it proceeds.
Blast Radius
How many users, systems, or workflows would be affected if this specific change behaves unexpectedly.
Reversibility
How quickly and cleanly this specific change can be undone if required.
Dependency Exposure
Which downstream systems or teams are affected by this deployment, and whether they have been informed.
The Progressive Rollout Pipeline
Exposure Increases Only When the Evidence Supports It.
Canary (small percentage) → Monitor defined signals → Expand exposure → Monitor defined signals → Full rollout. At any point in this sequence, a rollback is a designed outcome — not an emergency improvisation. Expansion to the next stage is a decision made against evidence gathered at the current stage, not a default that happens automatically with time.
This approach reflects the concept of an error budget, described in Google's Site Reliability Engineering (2016): a defined, acceptable amount of instability that a system is permitted to spend, used to make the trade-off between release velocity and reliability an explicit, measured decision rather than an implicit one.
Enablement: Documentation & Team Readiness
A System Nobody Can Operate Has Not Really Been Deployed.
Deployment is frequently treated as complete once software runs in production. OpenQCore treats it as complete only once the people responsible for operating, supporting, and troubleshooting that software are actually prepared to do so.
Operational Runbooks
Documented procedures for common operational tasks, known failure modes, and how to respond to them.
On-Call Readiness
Confirmation that the people responsible for responding to incidents have the access, context, and escalation paths they need.
Knowledge Transfer
Explicit handoff of operational understanding to the team or organization who will own the system going forward.
The Deployment Decision Gate
A Deployment Proceeds Because Evidence Supports It — Not Because It Is Scheduled.
Every planned deployment reaches a defined decision gate before it proceeds.
Deploy
Risk assessment, rollback plan, and readiness are all satisfied — the deployment proceeds.
Delay
An identified risk has not yet been sufficiently mitigated — the deployment waits until it has been.
Rollback
A deployed change has triggered a defined rollback condition — the previous state is restored.
Escalate Incident
A deployment has caused an impact requiring a formal incident response beyond a standard rollback.
A deployment gate that never delays or rolls back is not evaluating risk — it is simply recording a schedule.
What This Stage Produces
A Live System, and the Capability to Operate It.
Depending on engagement scope, this stage produces:
Deployment Runbook
The specific, repeatable procedure used to deploy this change and future changes like it.
Rollback Plan
The defined trigger conditions, procedure, and recovery time objective for reversing this deployment.
Environment Promotion Record
Documentation of how the change moved through development, staging, and production, and what was verified at each stage.
Risk Assessment Document
The blast radius, reversibility, and dependency exposure evaluated before deployment.
Team Enablement Materials
Runbooks, on-call readiness confirmation, and the knowledge transfer completed before handover.
Progressive Rollout Report
The signals observed at each stage of exposure, and the evidence supporting expansion to full rollout.
From Deployment to Monitoring & Optimization
Live Is Not the Same as Understood.
Deployment & Enablement produces a system that is running safely in production, with the people responsible for it prepared to operate it. It does not yet produce a continuous understanding of how that system behaves over time, or a structured mechanism for improving it. That is the purpose of the next and final stage in this methodology.
Controlled Production Exposure → Operational Readiness → Monitoring & Optimization
Step 06
Monitoring & Optimization
Understand how a live system actually behaves, and improve it continuously against real evidence.
Research & Methodological References
Forsgren, N., Humble, J., & Kim, G. — Accelerate: The Science of Lean Software and DevOps (2018); Google Cloud, DORA State of DevOps research
Source of the deployment frequency and recovery time metrics referenced above.
Humble, J. & Farley, D. — Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (2010)
Source of the deploy/release distinction, blue-green deployment, and infrastructure-as-code principles referenced above.
Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (eds.) — Site Reliability Engineering: How Google Runs Production Systems (2016)
Source of the error budget concept referenced in the progressive rollout section above.