Creating releases and deploying code on Acquia Cloud

Branching strategies

For information about branching strategies, see the Git workflow section of the Dev Workflow document.

Tagging

Whenever the 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), you should create a tag. Common practices would have you use semantic versioning to name tags (for example, 1.0.0 or 1.2.3).

To create a tag, check out the master branch locally and then run the git tag command, similar to the following:

git checkout master
git tag 1.0.0

If you have a continuous integration environment that uses Travis CI or the Acquia Cloud pipelines feature, whenever you push the source tag to your GitHub repository, an artifact tag corresponding to your source tag will be created and pushed to Acquia Cloud. The tag name will be name of the source tag with -build appended. For example, a 1.0.0 source tag would make a tag named 1.0.0-build.

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 (for example, 1.0.0) based on the master branch in your repository.

Deploying tag and executing updates

Deploying Drupal across environments can be daunting, but if you use due diligence with your configuration management, the process of deployment can be straightforward.

Regardless of the number of environments or the versioning workflow in use, the actual deployment process will occur similar to the following:

Note

The following commands are examples.

• Enable maintenance mode for your website, using the following command:

  copy

  drush vset maintenance_mode 1

• Flush the website s caches to empty the cache tables and ensure maintenance mode is enabled:

  copy

  drush cc all

• Perform any necessary backups, including the database:

  copy

  drush sql-dump > backup-yyyy-mm-dd.sql

• Pull the latest code to the server:

  copy

  git pull origin/master

• Run update.php.

  copy

  drush updb -y

• Disable maintenance mode for the website:

  copy

  drush vset maintenance_mode 0

• Clear the website s Drupal caches again:

  copy

  drush cc all

Be aware of the following suggestions for actions to avoid for your production websites:

• Do not run drush cc all: Whenever possible, attempt to target specific caches.
• Do not use drush use: This command introduces the risk that the release master will accidentally run a command against prod after the release.

Depending on the infrastructure and the extent of website changes, you may need to compete some additional steps. For example, a major application change may require a flush of other caches in the system, such as Varnish or Memcached.

Notifications

You can configure several tools to provide notifications of deployment related events, including the following:

• Travis CI can notify you about your build results using email, IRC, or webhooks.
• Jenkins has plugins to provide build notifications using several services, including Slack and IRC.
• You can use Acquia Cloud Hooks to provide deployment-, database-, or code-related notification to services, such as the following:
  • New Relic
  • Slack
  • HipChat

Additional Resources

• Connecting the Tubes: JIRA, GitHub, Jenkins, and Slack