Our original deployment workflow at Knectar involved the following post-deployment script in Drush:

# run database upgrades if there are any, (and enable new modules/features
drush updb -y

# revert all features if any have changed
drush fra -y

# clear all caches
drush cc all

While bulky and slow, this script reinforced two important developer guidelines that developers working at Knectar have agreed to:

  1. Any changes should be automated, so that human error is eliminated when deploying new features or  site changes.
  2. On a stage or production machine, all features should always be completely reverted.

The above script also eliminated a huge pet peeve in our office: when a developer deploys a change but the cache does not get cleared, and our project managers think that tickets that have been marked as “resolved” need to go back to the developers.

However, this script worked only on a site with a single developer, who pushed regularly in longer intervals. Once it was implemented on a larger, multi-developer site, and multiple pushes were coming rapidfire and being continuously integrated with the staging server, we started to see pretty serious lags on the performance of the integration site. This ended up wasting the time of our project managers, who had trouble confirming that new features were being properly deployed.

During the development of a recent site, one of the coding developers inquired about a way to make the whole process less invasive.

I turned to the following documentation on the Beanstalk website:

SSH Variables
SSH Commands

I learned that Beanstalk will pass the most recently made Git repository/branch comment to the post-deployment script, as a variable (%COMMENT%) that can be utilized for a SFTP or SSH deployment server, which is set to auto-deploy whenever new changes are pushed to a certain branch.  This created a new opportunity to pair a feature update commit of changes with a flag to revert the features on the stage site…all without the unnecessary load of a database update or a “clear all caches” command. It also allows for front-end developers to attach less weighty commands to commits to make sure that any new css/js changes are included in a site’s js/css aggregated files, without having to clear the entire cache.

The end result is a 30 line shell script that allows for “power commit messages.” For example, a commit like:

[#12 state:resolved responsible:’Project Manager’] Updates made to the following projects:… -updb-“

will trigger a Drush upload on the development layer.

All of the triggers are covered in the documentation on the GitHub page.

Config