Deployment Strategies

This guide explores the various deployment strategies available in Aperture, explaining not just how to implement them but why and when each strategy is most effective for your business goals.

Understanding Deployment Risk

Before choosing a deployment strategy, it’s essential to understand what’s at stake:

User Experience Impact

Updates can disrupt user flows if not carefully managed, leading to confusion or frustration.

Brand Reputation

Buggy deployments damage trust and satisfaction, potentially impacting your relationship with users.

Revenue Implications

Issues affecting checkout or core features directly impact revenue and business operations.

Support Burden

Problematic deployments increase support tickets and costs, straining your resources.

The right deployment strategy mitigates these risks while enabling you to ship updates quickly and confidently.

Progressive Rollouts

A progressive rollout gradually increases the percentage of users who receive an update, allowing you to monitor for issues before affecting your entire user base.

Why Use Progressive Rollouts?

Progressive rollouts are ideal when:

• You’re deploying significant changes to core functionality
• You want to ensure server infrastructure can handle new features
• You need to validate performance in real-world conditions
• You’re concerned about potential edge cases not caught in testing

How to Implement a Progressive Rollout

Step 1: Plan your rollout phases

Example timeline:

• Phase 1: 5% of users for 4 hours
• Phase 2: 20% of users for 12 hours
• Phase 3: 50% of users for 24 hours
• Phase 4: 100% of users

Step 2: Configure in Aperture

1. Navigate to: Your web application → Deployments → New Deployment
2. Select: “Progressive Rollout” strategy
3. Configure each phase with:
   • Percentage of users
   • Duration before next phase
   • Automatic advancement conditions

Step 3: Set safety thresholds

Configure automatic rollback conditions:

• Error rate threshold: e.g., >2% error rate triggers rollback
• Performance degradation threshold: e.g., >30% slower page loads
• Custom metrics: Application-specific thresholds

Real-World Example

When Spotify deployed their redesigned home screen, they used a progressive rollout starting with 5% of users for two days, then gradually increased to 100% over a week. This allowed them to identify and fix several edge cases before most users encountered them.

Available in all plans

Cohort-Based Deployments

Cohort-based deployments target specific segments of your user base defined by characteristics like behavior, demographics, or opt-in status.

Why Use Cohort-Based Deployments?

Cohort targeting is powerful when:

• Testing new features with specific user segments before global release
• Deploying region-specific functionality or content
• Offering premium features to certain subscription tiers
• Conducting A/B tests to compare feature variations
• Allowing opt-in beta access to upcoming features

How to Implement Cohort-Based Deployments

Step 1: Define your cohorts

1. Navigate to: Cohorts → New Cohort
2. Define criteria such as:
   • User properties (location, language, subscription tier)
   • Behavioral traits (usage frequency, feature adoption)
   • Opt-in status (beta program participants)

Step 2: Create targeted deployment

1. Navigate to: Your web application → Deployments → New Deployment
2. Select: “Cohort-Based” strategy
3. Choose the cohort(s) to target
4. Configure rollout settings for the selected cohorts

Step 3: Monitor and compare

Track metrics comparing:

• Target cohort vs. general population
• Between different cohorts if testing variations
• Before vs. after deployment for the affected cohort

Real-World Example

Netflix regularly uses cohort-based deployments to test new UI features. They might target “power users” who watch more than 20 hours per week to test advanced recommendation algorithms, gathering feedback before deciding whether to roll out to all users.

Pro and Enterprise plans only

Device-Based Deployments

Device-based deployments target users based on their device characteristics, such as model, OS version, or form factor.

Why Use Device-Based Deployments?

Device targeting is crucial when:

• Rolling out features that require specific hardware capabilities
• Addressing OS-specific bugs or compatibility issues
• Optimizing for different screen sizes or device capabilities
• Phasing out support for older device versions

How to Implement Device-Based Deployments

Step 1: Define device criteria

1. Navigate to: Your web application → Deployments → New Deployment
2. Select: “Device-Based” strategy
3. Configure device filters:
   • OS version (e.g., iOS 15+, Android 10+)
   • Device models (e.g., iPhone 11 or newer)
   • Screen size categories
   • Hardware capabilities

Step 2: Create the deployment

1. Select the build to deploy
2. Choose the native applications to target
3. Configure any additional rollout settings
4. Set monitoring thresholds specific to these devices

Real-World Example

When introducing ARKit features, a retail app might deploy an AR shopping experience only to iOS devices with LiDAR sensors first, then expand to devices with less precise AR capabilities once they’ve validated the experience degrades gracefully.

Pro and Enterprise plans only

Hybrid Deployment Strategies

Hybrid strategies combine multiple deployment approaches for maximum flexibility and risk management.

Why Use Hybrid Deployment Strategies?

Hybrid approaches excel when:

• You need complex, multi-faceted rollout plans
• Different features have different risk profiles
• You want to isolate specific aspects of a deployment

How to Implement Hybrid Strategies

Example: Progressive Cohort Deployment

1. Define a “Beta Testers” cohort
2. Deploy to 100% of Beta Testers
3. Monitor for 48 hours
4. If stable, begin progressive rollout to general users:
   • 5% for 24 hours
   • 20% for 48 hours
   • 100% if all metrics remain stable

Example: Segmented Device Strategy

1. Deploy to newer device models first (100%)
2. Monitor performance and compatibility
3. Gradually include older device models in phases
4. Exclude incompatible devices entirely

Real-World Example

When launching a major redesign, Instagram used a hybrid approach: first deploying to their beta tester cohort, then to Android devices (which could be updated more quickly without App Store approval), then a progressive rollout to iOS users starting with newer devices.

Pro and Enterprise plans only

Feature Flagging and Canary Deployments

Feature flags allow you to toggle features on/off without redeploying. Canary deployments are a specialized form of progressive rollout where you test with a small subset before wider release.

Why Use These Approaches?

These strategies are valuable when:

• You want to ship code but not activate functionality immediately
• You need to quickly disable problematic features
• You want to test in production with minimal risk
• You need different feature sets for different user segments

How to Implement Feature Flagging

Step 1: Design with feature flags

Ensure your code uses conditional logic tied to feature flags:

if (featureEnabled('new-checkout-flow')) {
  // New checkout code
} else {
  // Old checkout code
}

Step 2: Configure in Aperture

1. Navigate to: Features → Feature Flags
2. Create flags with:
   • Default state (on/off)
   • Rollout percentage
   • Cohort targeting
   • Kill switch options

Real-World Example

Facebook deploys most new features behind feature flags, allowing them to gradually increase visibility from employees only, to beta testers, to a small percentage of users, and finally to everyone—all without changing the deployed code.

Pro (basic) and Enterprise (advanced) plans only

Rollback Strategies

Rollback strategies are pre-defined plans for quickly reverting to a previous stable state when issues are detected.

Why Prepare Rollback Strategies?

Robust rollback processes are essential because:

• Issues can appear despite thorough testing
• Fast recovery minimizes user impact
• Some problems only emerge at scale
• Quick response reduces negative feedback and ratings

How to Implement Effective Rollbacks

Step 1: Preserve previous versions

1. Configure Aperture to maintain the previous 3-5 stable builds
2. Ensure proper versioning and tagging of all deployments

Step 2: Define automatic rollback triggers

1. Navigate to: Your web application → Deployment Settings → Rollback Configuration
2. Set thresholds for:
   • Error rates (e.g., JavaScript exceptions)
   • Performance metrics (e.g., page load time)
   • Custom business metrics (e.g., conversion rate)

Step 3: Practice and document manual rollback procedures

1. Document the exact steps for manual rollback
2. Conduct periodic drills to ensure team familiarity
3. Assign clear responsibilities during incidents

Real-World Example

When Cloudflare deployed a configuration that caused a global outage, their well-practiced rollback procedures allowed them to restore service within 27 minutes of the initial problem—far faster than diagnosing and fixing the root cause would have taken.

All plans (automatic triggers limited in Starter plan)

Deployment Strategy Comparison

Strategy	Use Case	Risk Level	Available In
Full Deployment	Minor updates, fixes	Highest	All plans
Progressive	Major features, redesigns	Medium	All plans
Cohort-Based	Targeted features, beta testing	Low	Pro, Enterprise
Device-Based	Hardware-dependent features	Medium	Pro, Enterprise
Hybrid	Complex, multi-faceted releases	Variable	Pro, Enterprise
Feature Flags	Conditional functionality	Lowest	Pro (basic), Enterprise (advanced)

Deployment Schedule Best Practices

When planning your deployments, consider these best practices:

Timing Considerations

• Avoid peak usage hours unless deploying critical fixes
• Consider geographic distribution of your user base when scheduling
• Align with support team availability for faster response to issues
• Schedule progressive phases to ensure observation during business hours

Deployment Frequency

Different approaches work for different organizations:

• Continuous Deployment: Multiple small deployments daily (low risk, fast iteration)
• Regular Scheduled Releases: Weekly or bi-weekly deployments (balanced approach)
• Major Release Cycles: Monthly or quarterly releases (traditional approach)

The right frequency depends on your team size, application complexity, and business requirements.

Next Steps

Now that you understand deployment strategies:

1. Assess your application’s risk profile to determine appropriate strategies
2. Document your organization’s deployment protocols
3. Configure default deployment templates for your common scenarios
4. Train your team on deployment and rollback procedures