Cloud Platform
Using the recommended workflow
Acquia recommends you have the following working environments, in addition to the RA environment provided by Acquia:
Environment | Description |
|---|---|
Production (Prod) | The production environment contains your live code. No testing takes place here, and all production code is ran from a tag, not a branch. |
Staging (Stage) | Acquia uses the staging environment to deploy and test small changes or security updates, and to perform a final test of a development branch or tag before going live. Your staging and production environments should be on the same tag, except when you are testing a new tag on staging for imminent deployment to production. |
Development (Dev) | Active development and testing occurs on your development environment.
Development should be on a branch or |
Remote Administration (RA) | Acquia provides an additional RA environment to facilitate security updates. Acquia uses the RA environment for the proactive process of deploying and testing security updates before deploying them to production. Acquia will overwrite the code and databases on the RA environment on a regular basis. You should use the RA environment only for testing security update branches. For more information about the RA environment, see Environment. |
Acquia recommends your version control system (VCS) workflow has the following attributes:
Master (Git) is always a stable, up-to-date codebase.
Your master branch should be deployable to production unless updates
are in process. The master is deployed to your development environment
unless testing is in process.
Branches are used for developing and testing new code and updates.
Branches are taken from the production tag. Acquia labels branches
according to the function, the date and time started (for example,
AcquiaRA-2018-02-12-13-14-15).
Development can happen in parallel on different branches.
Acquia recommends you keep track of the changes you will eventually merge
into master, and update the branch with master on a regular basis
to ensure the working branch is up-to-date. Depending on the kind of
development on the branch, this may not be possible. During the automated
RA update process, do not merge these changes into master or deploy
them to production until after the RA update process has completed and the
update branch has been merged back into the main branch.
All tested and approved branches should be merged back into master.
After you fully test your development branches, you should merge them
into master, ensuring master always includes updated code.
Tags from tested and approved branches (including the master) are used for production. Tags are snapshots of your code, frozen in time and unchangeable. You may not make a commit against a tag. By not modifying tags, you can easily revert to a previous tag if you discover an error on the most recent tag.
If this content did not answer your questions, try searching or contacting our support team for further assistance.
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Cloud Platform