Deployment (2019)
Deployment practice and workflows from March 2019.
Deployment step-by-step Workflow.
The following is a table showing the various stages of a deploy to production.
Developer checks out the
developbranch of the main repository.Developer builds local docker container, and builds Drupal site in container.
Developer creates new working branch e.g.
my-branch.Developer makes necessary changes to website and/or to PHP code.
Developer tests changes locally.
There are scripts which can be used to make the container and build Drupal.
Important - don't forget ....
Developer updates features (using Drupal features module) as needed.
Developer commits code and features changes to
my-branchbranch of local repository.Develop runs local PHPUnit, behat and linting tests.
Developer pushes local branch
my-branchto a branch of the same name (i.e.my-branch) on the CoB GitHub repository.
Developer creates a new Pull Request (PR) to merge
my-branchintodevelopon the boston.gov-d7 GitHub repository.Developer provides appropriate notes (in template form) in the PR comments.
Developer assigns a peer-developer to review the code.
Once a new PR to develop is created in GitHub, Travis starts a build verification process, which attempts to build a new Drupal site from the files my-branch, and then run various linting, PHPUnit and Behat tests.
Developer merges
my-branchintodevelopwhen the peer-review is complete and the Travis build tests pass.Developer deletes
my-branchlocally and on GitHub when the merge todevelopis complete.
It is acceptable to use the GitHub "Squash and Merge" function when merging a branch into develop.
Travis monitors the GitHubdevelop branch, and when a commit is performed (either a direct commit or a merge process) to the branch Travis starts a deploy process:
The devAcquia server/environment monitors the Acquia develop-buildbranch and when that branch is updated (i.e. a merge/commit is made) it automatically pulls the updated code onto the appropriate server, and
backs up the database on the Acquia
devenvironmentcopies the database from the Acquia
stageenvironment to the Acquiadevenvironment.runs processes on the
devenvironment to sync the (updated) code and the (copied) database.
A Senior Developer from the team creates a PR to merge
developintomasterwhen a deploy is desired. Ideally this is done frequently with just a single branch pre-deploy.Reviewers are assigned (see reviewer notes here):
The City of Boston Website Product Manager, and
QA representative.
The Senior Developer merges the PR into
master.
Do not use GitHub's "Squash and Merge" feature when merging the PR as this breaks consistency between master and develop on GitHub.
Travis monitors the GitHub stage branch, and when a commit is performed (either a direct commit or a merge process) to the branch Travis starts a deploy process:
The stageAcquia server/environment monitors the Acquia master-buildbranch and when that branch is updated (i.e. a merge/commit is made) it automatically pulls the updated code onto the appropriate server, and
backs up the database on the Acquia
stageenvironment, andcopies the database from the Acquia
prodenvironment to the Acquiastageenvironment, andruns processes on the
stageenvironment to sync the (updated) code and the (copied) database.
After testing is competed:
The City of Boston Website Product Manager (or someone delegated) completes change and release documentation, and
Ensures the developer(s) who made the changes in the release is available in case of issues in production, and then
Using the Acquia Cloud web-UI: the Product Manager (or someone delegated) drags the code from the
stageenvironment to theprodenvironment.
Acquia-hooks will detect that the code has been moved and will:
backup the
Productiondatabase,run drush commands to update configurations from the new code into the
Productiondatabase.
==========================================================================
Deployment Engineering.
The automated deploy process follows continuous deploy (CD) principles whereby:
The deploy workflow is engineered so that all developers are able and enabled to perform a deployment,
Wherever possible, the workflow is automated to remove the need for manual tasks and testing.
The primary tools used by City of Boston in the CD workflow process are:
Docker to manage local development environments.
GitHub for code storage and deploy initiation.
Travis for automated testing, building and packaging.
Acquia Cloud (acapi and cloud webhooks) for deployment.
Secondary tools used by City of Boston in the CD process are:
Phing to abstract scripting processes used in build, test and packaging.
PHPUnit and behat to perform automated testing.
Overall the engineering workflow is as follows:
www.boston.gov and hub.boston.gov
City of Boston operate 2 websites (hub and boston), each being an "application" on Acquia. The Drupal code-base on the 2 websites is very similar, the main differences being some settings files and the content contained in the applications database.
The overall engineering utilizes a single repo in GitHub, and a single repo in Acquia's Git.
The workflow engineering creates and manages a single develop and single master branch in GitHub -these ultimately are common to hub and boston websites.
However, the Acquia environments (dev, stage, prod) in each application (boston, hub) are attached to different branches of the Acquia git. Hub branches are suffixed with -hub. These branches are created by and during the Travis packaging process.
Last updated
Was this helpful?