Creating Releases

Repo Summary

There are three repositories at present for Acquia CMS.

acquia/acquia_cms - this repository, from which development happens and all releases are started.
acquia/acquia-cms-project - the public facing repository (eventually), from which customers will run composer create-project and our UIs will pull deploy artifacts.
acquia/sf-acms - a Site Factory specific repository that builds and stores its' own version of ACMS releases, customized to run inside ACSF.

There are two integration applications for ACMS in Acquia Cloud, each with their own environments:

Developers checkout a feature branch in a CloudIDE or their development machines, make code commits.
Developers push their feature branch and open a PR against the 'develop' branch.
Travis automated tests will run, and if they pass and all peer-review feedback has been implemented, a technical lead will merge the PR.
This will deploy the merged commits to our ACE integration environment.
Overnight builds on acquia/sf-acms to deploy the commits to our ACSF development environment.

A release engineer (RE) will create a tag on the final commit in the develop branch for the current release.
Optionally, they may open a release branch, and cherry pick commits into that branch if it's necessary to omit commits for work that is still in progress. They would then apply the release tag to HEAD of the release branch.
The RE will then deploy the new tag to the Stage environment in our ACE integration environments, where UAT will start.
The RE should then create the release tag on the ACSF integration environment and deploy it to ACSF. UAT will complete there.
The RE should then deploy the release tag to the prod environments in ACE and ACSF, and confirm that updates to existing test builds in those environments behave as expected.
The RE should also build a new test site in ACSF production, to verify new installs.
If a Staging or Production deployment uncovers a bug, we'll follow the hotfix process defined below.
Once UAT and production deploy tests are completed, and the release is certified, a PR will be issued to merge the release commits (and its' tag) into the 'main' branch. HEAD on 'main' should always represent the most recent known deployable state at any given point in time.
The RE should then create a branch for the release on acquia-cms-project.
The RE will create Github releases on the main repo and ACSF repo.
Product and the technical lead will work together to create release communications to be distributed within Acquia (process TBD).

In the event of a failed release deployment to any of our Staging or Production environments, we'll perform a hotfix.
Once the issue has been validated and recreated reliably, a bugfix will be prioritized and delivered through the standard development PR workflow. The PR should be merged into the develop branch.
In the case of a hotfix after a published release, the RE will create a hotfix branch off of main and cherry-pick the PR fix commits into the hotfix branch. The hotfix then goes through the release workflow described above.
In the case of a failed release candidate, the PR fix commits will be cherry-picked into the release branch, and the tag will be moved to the new commits (now HEAD). The release branch now re-enters the release workflow described above.

Ask the product owner to have a release version created in JIRA, and tag all tickets with the release version.
Update the release versions list on the project home page in Confluence.

acquia/acquia-cms-project is the repository customers should use for their applications. The composer.json for that project will pull in any tagged releases with a simple composer update. Similarly, the composer.json for SF-ACMS will pull in releases from ACMS.