Dark Launching

Overview

Dark launching is the practice of deploying new features to production without exposing them to users immediately. The features are live in the system, but access is restricted — typically via feature flags, internal toggles, or conditions.

The code runs in production, but the functionality is hidden or only enabled for internal/test users.

How It Works

1. New code is deployed to production alongside existing code.
2. A feature flag or toggle controls whether the feature is active.
3. For most users: the feature is off or hidden.
4. For test groups/devs/internal users: the feature can be manually or conditionally turned on.
5. Metrics and logging collect data on usage, performance, or errors.

Advantages

Benefit	Why It Matters
Safe early deployment	Push code to production before public use.
Real-world testing	Observe performance and behaviour in a production environment.
User control	Gradually release to internal teams or specific users.
Early feedback	Internal stakeholders can test and give feedback.
Fast rollback	Turn off the feature with a flag instead of redeploying.

Drawbacks & Risks

• Code complexity: Conditional logic and flags can clutter code.
• Testing depth: May not catch all user-facing issues until fully released.
• Hidden costs: Keeping dark-launched features unused for too long can create tech debt.
• Security risk: If not well controlled, hidden features may be accidentally exposed.

Common Use Cases

• Launching a major UI change but only enabling it for staff first.
• Testing new recommendation engines or algorithms without affecting users.
• Preparing for a big marketing launch while features are already deployed.
• Gathering telemetry and performance data in production.

Example in C# with Feature Flags

public IActionResult Dashboard()
{
    if (FeatureFlags.IsEnabled("NewDashboard"))
    {
        return View("NewDashboard");
    }

    return View("OldDashboard");
}

• The NewDashboard view is deployed but only shown if the flag is enabled.
• Telemetry could still be collecting load time or error info on the dark-launched version.

Comparison with Related Strategies

Strategy	Users Affected	Goal	Key Difference
Dark Launch	None or internal	Deploy early, test silently	Feature is in prod, but not exposed
Canary Release	Small subset	Gradual public exposure	Exposed to real users in limited %
A/B Testing	Split groups	Compare versions	Two+ versions exposed and compared
Feature Flags	Any subset	Dynamic enable/disable	Mechanism to implement dark launches etc.

How to Implement in Azure

• Use Azure App Configuration + Feature Manager to toggle features.
• Track dark-launched feature metrics via Azure Monitor or Application Insights.
• Combine with Azure Deployment Slots to separate test/staging traffic if needed.

When to Use Dark Launching

Ideal when:

• You want to deploy code early and validate in production.
• You need internal stakeholders to test before public release.
• The feature is complex and needs real-world telemetry before full exposure.

Not ideal when:

• The feature depends heavily on real-time user feedback.
• You lack a good system for feature flags or role-based access.
• You cannot afford the risk of partial exposure.

Summary

Aspect	Detail
What it is	Deploying features to production but hiding them from end users
Mechanism	Feature flags, role-based access, or internal toggles
Use Cases	Internal testing, performance checks, marketing prep
Azure Support	Azure App Configuration, Feature Manager, Application Insights
Risk Level	Low for users; Medium for complexity and oversight