Skip to content

Latest commit

 

History

History
55 lines (35 loc) · 3.16 KB

release-process.md

File metadata and controls

55 lines (35 loc) · 3.16 KB

Release Process

Branching strategies

@todo Document this!

Generating a build artifact

See Create and deploy the build artifact in deploy.md.

Tagging

@todo Document this!

Release notes

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):

  1. Put the site into maintenance mode drush vset maintenance_mode 1
  2. Flush Caches to empty the cache tables and ensure maintenance mode is set. drush cc all
  3. Perform any necessary backups, notably the database drush sql-dump > backup-yyyy-mm-dd.sql
  4. Pull the latest code onto the server git pull origin/master
  5. Run update.php drush updb -y
  6. Take the site out of maintenance mode drush vset maintenance_mode 0
  7. 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 hook_update_N() implementation.
  2. Run drush cc all. Specific caches should be targeted whenever possible.
  3. Utilize 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.

Notifications

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:

Resources: