The dilemma
Teams often debate whether a strict pre-launch freeze prevents self-inflicted outages or simply accumulates delta risk that explodes during release. A complete freeze protects staging and production state from unexpected regressions, ensuring test stability at the cost of delayed integration and post-freeze deployment queues. Conversely, continuing to ship small updates keeps deployment pipelines warm and minimizes delta sizes, but introduces the risk that an unrelated commit causes a late-breaking regression. Meanwhile, relying on dark launching and feature toggles allows code to soak in production safely, but adds flag debt and operational complexity.
- a· Implement a complete code and deployment freeze
- b· Maintain continuous production shipping of small changes
- c· Decouple deployment from release via dark launching
Verdict
Decouple deployment from release via dark launching
Option C (dark launching via feature flags with continuous deployment) dominated the discussion. Engineers favored it because it allows testing launch-ready code in the live production environment to catch integration and infrastructure issues early, avoids accumulating a massive deployment queue on launch day, and enables immediate rollback by simply toggling a flag.
- Implement a complete code and deployment freeze11%
- Maintain continuous production shipping of small changes5%
- Decouple deployment from release via dark launching84%check
Published answers (7)
Members choose to publish their answers.
@shreerajshah-dukkin a· Implement a complete code and deployment freeze
13 OctThis strategy works the best and hassle free because the code is already thoroughly checked and fixed if it had any bugs. if something happens after the deployment there is a high chance it can be resolved quickly... there can be one more strategy in which the update is deployed when there is the lowest user activity time period and can put the timer according to the update let's say (5-15 mins max) to check for the bugs and the only problem is that developer's cant determine if the code will perform the same in peak hours.
@xenitane c· Decouple deployment from release via dark launching
13 Oct- Since the roll-outs are behind feature flags, the end-user can't use them and this won't create conflicts as the new features evolve architecturally. - The roll-out being behind a feature flag helps with incremental releases, i.e. enable to a small segment, check for potential risks, pitfalls, improvements, etc.
@algobrother c· Decouple deployment from release via dark launching
13 OctDuring the final pre-launch week, we can continuously deploy and validate launch-ready code in production while keeping new features disabled behind feature flags. This allows us to catch integration issues and infrastructure-related defects before launch, rather than accumulating changes and discovering problems at the last minute. A complete freeze like [A] blocks all potential progress and [B] risks some more extra potential bugs during prod launch.
@A member c· Decouple deployment from release via dark launching
13 OctI would choose dark launching with feature flags to deploy code safely without exposing unfinished features to users. I would monitor errors and performance , gradually release the feature using canary rollouts, and roll back immediately if issue arise. This minimises the risk while ensuring launch day stability.
@vasusharma001-hash c· Decouple deployment from release via dark launching
13 OctConsidering , we have to take a decision which reduces risk in main production product and at the time we have to ensure launch day stability of the product . we should do a dark launch of the product (A beta version of the product and give access to limited users ) , they could be the own company developers or testers. this approach would reduces the risk of crashing out of product while real user experience it and at the same time the company could fix the bugs and issues before the product reaching out to the real users which will lead to the launch day stability .
@0xnotayu c· Decouple deployment from release via dark launching
13 OctOption C Feature flags keep unfinished features hidden from users. Code runs in the production environment, exposing infrastructure and integration issues before launch. The team can enable the feature when ready without needing a new deployment. Continuous deployment avoids accumulating a large release delta.
@keshav1602 c· Decouple deployment from release via dark launching
13 OctThis is flag based deployment very effective we can test and deploy feature that are not visible to the user. We can even enroll the feature to a set of user to test by modification In A we can do it if the timeline is something that is not hard fixed. In b there can be a lot of issues with integration of code with environment or infra.
More Calls
- 14 OctWhen defining operational incident response procedures for complex backend systems, which runbook architecture provides the superior default balance between operator safety, execution flexibility, and long-term maintainability?
- 12 OctWhen configuring actionable page-level alerting for high-throughput production services, which alerting strategy provides the superior balance between fast incident response, low alert fatigue, and operational sustainability?
- 11 OctWhen validating service capacity and performance under load, which strategy provides the superior default balance between operational safety, scenario flexibility, and realistic behavioral accuracy?