1.1

Cloud Features & Functions

Describe the features and functions of Magento Commerce Cloud: Platform overview, Starter vs Pro editions, branching workflows, and deployment processes.

Exam Critical: Commerce Cloud topics appear on the AD0-E717 certification exam! Understanding Cloud architecture, editions, workflows, and deployment processes is essential for both the exam and real-world cloud development.

Magento Commerce Cloud

mindmap root((Commerce Cloud)) Platform Built on AWS Based on Platform.sh Managed code and environment Editions Starter shared hosting Pro dedicated instances Starter Workflow master production staging replicates prod integration branches work Pro Workflow integration base staging testing master production Data Flow Production to Staging to Integration Code Flow Integration to Staging to Production

What is Magento Commerce Cloud?

Magento Commerce Cloud is a hosting platform built on AWS to host Commerce projects.

Platform Overview

  • Built on Platform.sh infrastructure
  • Includes many value-add features
  • Magento manages both code and environment
  • Most qualified hosting platform for Commerce
Key Benefit: Fully managed environment optimized specifically for Magento Commerce.

Cloud Editions: Starter vs Pro

There are two editions of Magento Commerce Cloud:

Feature Starter Pro
Hosting Shared hosting Dedicated AWS instances
Fault Tolerance Single server Three server setups
B2B Module Manual install via Composer Manual install via Composer
Deployment Path Integration → Staging → Master (Production) Integration → Staging → Production (8 active environments)
Primary Branch master = production integration = base for development

Pro Edition Exclusive Features

  • Dedicated hosting environment (dedicated AWS instances)
  • Three server setups for fault tolerance
  • B2B module (install manually via Composer, like on-premise)
  • 8 available active environments
  • More structured deployment path

Starter Edition Workflow

Starter utilizes the master branch for production. Code merges from staging to master deploy to production.

Key Concept: Opposite Flows

  • Code Flow: Integration → Staging → Master (Production)
  • Data Flow: Production → Staging → Integration (opposite direction!)
Why Opposite? Production is the single source of truth for database information.

Starter Branch Structure

  1. master: Production environment
    • Should have no changes made directly to it
    • Code pushed to staging automatically flows to master
  2. staging: Pre-production environment
    • Checked out from master
    • Closely replicates production with read-only file system
    • Branch from which you create integration branches
    • No direct changes should be made
  3. integration branches: Where work happens
    • Can have two active integration environments (activated in Cloud control panel)
    • Can push as many branches as you wish
    • Named whatever you wish (only "magic" names are staging and master)

Starter Development Workflow

  1. Check out staging
  2. Pull latest code for staging from platform remote
  3. Create integration environment branch (named as desired)
  4. Optionally create feature branch for specific work
  5. Make changes on feature branch (if used)
  6. Merge to integration branch and push → Deploys to integration environment if activated
  7. Merge integration to staging → Deploys to staging environment
  8. Final testing and approval
  9. Push to master → Releases to production

Pro Edition Workflow

Pro is more structured than Starter. The integration branch is where you create branches to develop new features.

Key Differences from Starter

  • Primary branch: integration (not staging)
  • master, staging, and integration are all protected (GitLab terms)
  • Child branches from integration activate environments
  • Must branch from integration, not staging
Recommendation: After merging staging to master, also push to global master branch.

Important Notes & Best Practices

Branch Hierarchy

  • No "hierarchy" of branches—staging is just "special"
  • For Pro: must branch from integration
  • For Starter: branch from staging

Module Management

  • Enable new modules locally first: bin/magento module:enable MODULE/NAME
  • Include app/etc/config.php in Git repository
  • Modules not explicitly disabled in app/etc/config.php are automatically enabled
Important: Do NOT enable modules directly in Cloud environment—do it locally first!

Environment Activation & Data

  • When new environment is activated, data is automatically copied from parent environment
  • Keep data regulations in mind—customer data will be copied!
  • Lead developer determines which branches should be activated as environments

Git Hosting Options

You can use GitHub, GitLab, or BitBucket instead of Magento git hosting.

  • Magento git benefit: See logs in Terminal when you git push
  • GitLab/GitHub benefit: Protect specific branches to prevent accidental pushes

Practical Experience: Initialize Environment

Setup Steps

  1. Clone repository to your system
    • Click "git" (with right arrow) to see git clone path
    • Can use magento-cloud commands (e.g., magento-cloud checkout)
  2. Configure project locally
    • Use master branch for Starter projects
    • Use integration branch for Pro projects
  3. Push to appropriate branch
  4. SSH into production and configure:
    • Create admin user
    • If Magento NOT installed, deploy will attempt auto-install

Reset an Environment

If you need to reset an environment:

  1. SSH into the branch's environment
  2. Run bin/magento setup:uninstall
  3. Clear all writeable files: rm -rf ~/*
  4. Flush Redis: redis-cli -h redis.internal FLUSHALL
  5. Push an empty commit to the branch
  6. Install Magento/import database

View Credentials

echo $MAGENTO_CLOUD_RELATIONSHIPS | base64 --d | json_pp

Shows database and Redis credentials.

Further Reading

Exam Tips

  • Platform: Built on AWS, based on Platform.sh, fully managed.
  • Editions: Starter (shared) vs Pro (dedicated, 3 servers, 8 environments).
  • Starter: master = production; branch from staging; staging → master.
  • Pro: integration = base; branch from integration; more structured.
  • Code Flow: Integration → Staging → Production.
  • Data Flow: Production → Staging → Integration (opposite!).
  • Modules: Enable locally first; include app/etc/config.php in Git.
  • Environments: Data auto-copied from parent; 2 active integration environments in Starter.