We use Composer to manage dependencies and upgrades in Magento Commerce and provide context about the included packages, what the packages do, and how they fit together. We highly recommend experience with Composer.
The following sections detail the specifics of Magento Commerce composer packages, how they work, and what they do within the code base.
For Magento Commerce (Cloud) 2.2, the
magento/magento-cloud-configuration (MCC) has been replaced by
magento/ece-tools. These packages decouple a patch update from a full product upgrade, allowing you to fully apply a patch without a full product installation or upgrade.
Your project’s Composer files
Your project root directory contains
composer.json to specify dependencies for your Magento Commerce project. For example, when you install an extension, you update
composer.json to add the extension to the list. you can either edit it manually or the Component Manager can do it for you.
composer.lock stores a set of exact version dependencies that satisfy all of the version constraints of every requirement for every package in the dependency tree of the project.
The following commands determine what’s in
composer update, which you must run every time you add or remove dependencies in
composer.json, to download dependencies.
You must keep an up-to-date copy of
composer.lockin your Cloud Git repository.
The workflow is as follows:
- Make a change to
composer.json. For example, edit this file when installing an extension.
composer.lockto or update it in your Cloud Git repository.
- Push the changes to the Cloud environment, which causes Cloud to build and deploy the environment.
During the build phase, the Cloud environment runs
composer install on a fresh clone of your Git branch to retrieve the latest dependencies.
Magento Commerce (Cloud) packages
The following sections discuss the Composer packages used by Magento Commerce:
magento/magento-cloud-metapackage should be the only package in the
require section of your
composer.json. This is a metapackage and does not contain any code.
The metapackage depends on the appropriate versions of
magento/product-enterprise-edition. At any given version, this package requires the same version of
magento/product-enterprise-edition. For example, to use Magento Commerce version 2.2.0, for example,
composer.json must specify a requirement for
magento/magento-cloud-metapackage version 2.2.0.
This package depends on a floating version of
magento/magento-cloud-configuration (abbreviated MCC). It depends on the major and minor version of MCC that correspond to the specified Magento Commerce version, and floats on the patch version so that compatible updates to this packages can be automatically pulled by running
This package contains patch files that are specific to Cloud. Patches are separate from tools, allowing you to apply patch updates without requiring a full upgrade and install of all Cloud code and the patch. Using
compuser update automatically runs tools to check for available patches and to run them with build and deploy scripts.
For Magento Commerce, versions are specified as
Patch versions are specified as:
<100 + x>.<y>.*. For example, Magento Commerce 2.2.0 is associated with
ece-patches 102.0.0. Subsequently, a new patch will be released that corresponds to the same Magento Commerce version, and it would be 102.0.1.
Code released in
ece-patches is strictly for updates to Magento Commerce (Cloud). Patches are available in the
To check for available patches, you can check in the
This package contains the following scripts and
magento commands that automatically perform building and deployment of the codebase on the cloud environment:
For Magento Commerce, versions are specified as
2.<x>.<y>. The versioning for
ece-tools will then be
<200 + x>.<y>.*. For example, Magento Commerce 2.2.0 is associated with 202.0.0.
We release updated
ece-tools code strictly includes improvements for tools, including the build and deploy hooks. These tools are updated as needed through patching and product upgrades, managed by the
This metapackage requires Magento application components, including modules, frameworks, themes, and so on.
Base packages and file marshaling
Magento contains two base packages,
magento/magento2-ee-base. These packages contain interstitial files that cannot be classified as extensions, themes, frameworks, or language packages; for example, sample server configuration files, PHP entry points, and so on.
These files are location-dependent, and cannot reside in the
vendor directory. They are distributed as part of the base packages, and they rely on hooks located in the
magento/magento-composer-installer package, which marshals them to the appropriate locations.
One way in which Magento Commerce deploys differently than other Magento installations is that it does not marshal base packages on the Cloud environment. This could change in a future Cloud release, but for now, on the Cloud environment specifically, the marshaling functionality of
magento/magento-composer-installer is disabled.
Therefore, when upgrading to a new Cloud version or adding, removing, or changing any packages that rely on file marshaling, you must:
The new version of the base packages are marshaled out into the Cloud project root directory, which means files are added, removed, and changed.
File marshaling works on your local system but not on the Cloud server.
- Add and commit these updated files to your Cloud Git repository.
- Push the changes to your Cloud Development (Integration) environment.
For more information, see Patch Magento Commerce (Cloud).
This makes sure that base files are placed in the correct location and are under source control. If you notice any problems after deploying an updated version of Magento, one of the first things to check should be whether all of the base package files were added to source control.