See the Git Workflow section of the Dev Workflow document for this information.
Generating a build artifact¶
master branch contains all of the desired commits for a release (regardless of the Git Workflow your team employed to arrive at the updated branch), a tag should be created. It is common to use semantic versioning to name tags: e.g.
A tag can be created by checking out the
master branch locally and executing the
git tag command:
git checkout master git tag 1.0.0
If you have a continuous integration setup via Travis CI or Pipelines, upon pushing the "source tag" to your Github repository, an "artifact tag" corresponding to your source tag will be created and pushed to Acquia Cloud with the same name, but "-build" tacked onto the end. A
1.0.0 source tag, for example, would end up generating a
If you are doing deployments manually, you will want to checkout your
master branch locally, and manually build a deployment artifact based off of that. Even if you build the deployment artifact manually, the recommendation is to still push up a source tag (e.g.
1.0.0) based on your
master branch to your repository.
Each release should be accompanied by a set of release notes, which can be easily generated using the Release Notes Script.
This script will automatically aggregate all of the descriptions from Pull Requests since a specified date. The generated tet aggregate can then be copied and pasted into release notes on GitHub.
Deploying tag and executing updates¶
Deploying Drupal across environments can be daunting, but if due diligence has been taken with configuration management, the process of deployment is actually quite simple.
No matter how many environments there are or whatever versioning workflow is being used, the actual deployment process will take approximately the following form (please note the commands are examples):
- Put the site into maintenance mode
drush vset maintenance_mode 1
- Flush Caches to empty the cache tables and ensure maintenance mode is set.
drush cc all
- Perform any necessary backups, notably the database
drush sql-dump > backup-yyyy-mm-dd.sql
- Pull the latest code onto the server
git pull origin/master
- Run update.php
drush updb -y
- Take the site out of maintenance mode
drush vset maintenance_mode 0
- Clear Drupal caches
drush cc all
A few things that you should (almost) never do on production:
1. Revert all features via
drush fra -y. This poses a site stability risk and also risks wiping a feature that may be been accidentally overridden in production. Feature should be explicitly reverted via a call to
features_revert_module() in a
drush cc all. Specific caches should be targeted whenever possible.
drush use. This introduces the risk that the release master will accidentally run a command against prod after the release.
There might be some extra steps depending on the infrastructure and the extent of site changes. For example, a major application change might require a flush of other caches in the system such as Varnish or Memcached.
You can configure various tools to provide notifications of deployment related events. For instance:
- Travis CI can notify you about your build results through email, IRC and/or webhooks.
- Jenkins has plugins to provide build notifications via Slack, IRC, and many more services.
- You can use Acquia Cloud Hooks to provide deployment, db, or code related notification to service such as: