Environment Types

Magento Commerce Cloud has three types of environments: Integration, Staging, and Production. Each serves a different purpose with unique characteristics.

Purpose

Integration environments are where active development work happens. This is where developers write code, test features, and prepare changes before promoting to staging.

Starter: Up to Two Active Integration Environments

• 2 active integration branches/environments
• Can create unlimited branches in git, but only 2 can be active (deployed) at once
• Branched from staging
• Development and testing happen here
• Writable file system

Pro: Official Integration + Up to Four Active Branches

• 1 official integration branch/environment
• Up to 4 additional active development branches (total: 5 development environments)
• Pro has an official integration environment that feeds up to staging
• Writable file system

In Pro, the integration branch/environment serves a special role:

• Source for all new branches
• All development branches should be created from integration
• Acts as the collection point for completed work
• Once code is merged into integration, it flows through: Integration → Staging → Production → Global Master

Hotfix Protocol for Pro

Any fixes or hotfixes should come from integration:

• Standard path: Create branch from integration → Merge to integration → Flow to staging/production
• Emergency only: Can push directly to staging and production if needed to get patch quickly
• But normal practice is to go through integration first

Purpose & Characteristics

Staging is the pre-production testing environment:

• One environment based on the staging branch in git
• Designed to closely replicate production
• Read-only file system
• All services available on production are also available on staging

Available Services on Staging

Staging includes all production services:

• Fastly (CDN)
• New Relic (monitoring)
• Blackfire (profiling)
• All other production-level services

Code Deployment to Staging

Standard deployment flow:

• Code should first be deployed to an integration branch
• Then promoted from integration to staging
• Then from staging to production

Emergency Direct Push

There is an exception for emergencies:

• If there's an emergency, you can push directly to staging or production
• This bypasses the normal integration → staging flow
• Should only be used in urgent situations

Characteristics

• One environment
• Read-only file system
• The master branch in git
• Live customer-facing site
• Highest level of stability and performance

Available Services

Production has full access to all services:

• Fastly - CDN for caching and acceleration
• New Relic - Application performance monitoring
• Blackfire - Performance profiling
• All other enterprise services

Deployment to Production

Standard flow:

• Code flows from staging to production
• Should be well-tested in staging first
• Emergency direct push possible but not recommended

Visual Structure

master (production)
  └── staging
       └── integration ← Branch from here!
            ├── development-branch-1
            ├── development-branch-2
            ├── development-branch-3
            └── development-branch-4

Important Pro Notes

• You should only branch from integration
• It's technically possible to create branches from other branches, but NOT recommended
• The integration branch serves as the source for all new development work
• Development branches are children of integration in the git repository

Normal Path (Starter)

1. Work on integration branch
2. Merge to staging for testing
3. Staging auto-merges to master (production)

Normal Path (Pro)

1. Create development branch from integration
2. Work on development branch
3. Merge to integration
4. Merge integration to staging for testing
5. Merge staging to master (production)

Emergency Path (Both Plans)

In emergencies, you can skip steps and push directly to staging or production:

• Use only when absolutely necessary
• Allows rapid hotfix deployment
• Should be followed up with proper merge through normal channels

Fastly (CDN)

• Available: Staging, Production
• Provides caching and content delivery acceleration
• Same configuration in staging as production

New Relic (Monitoring)

• Available: Staging, Production
• Application performance monitoring
• Track performance metrics and errors

Blackfire (Profiling)

• Available: Staging, Production
• Performance profiling tool
• Identify bottlenecks and optimization opportunities

Development Workflow

• Always develop in integration environments
• Test thoroughly before promoting to staging
• Use staging for final validation with production services
• Only promote to production after staging approval

Pro-Specific Practices

• Always branch from integration
• Merge completed work back to integration
• Use integration as the collection point before staging
• Keep development branches short-lived

Emergency Deployments

• Only use direct staging/production push for true emergencies
• Document the reason for emergency deployment
• Follow up by merging through proper channels
• Ensure changes are in integration for future branches