Cross-posted with permission from iKOS.com
If you are working on a project with multiple developers, it's likely the topic of Continuous Integration has come up. Whilst not the academic definition, I find a useful way to describe this is the ability to completely destroy and rebuild your site without losing anything.
When you start researching this topic, you will hear about tools such as Jenkins, Puppet, Chef and various hosted services that offer similar functionality. However if you host on Acquia Cloud, there is a less publicised feature at your disposal which means you may not need any of these things.
Acquia Cloud Hooks work like Drupal hooks except they are triggered by changes to your Acquia Cloud environment. For example, there is a Cloud Hook that is triggered in response to a new code deployment.
We've been able to use Cloud Hooks to fulfil some of the Continuous Integration work on our project without the need to set up external tools - giving us more time to focus on the project. The reason we use Acquia Cloud in the first place is so that we don't have to worry about hosting - features like this are the icing on the cake.
Here are some useful Cloud Hook scripts that automate our development and help me to sleep at night...
1. Automatically rebuild your site when a new tag is deployed.
Nightmare Scenario Avoided
A nightly build requires the site to be reinstalled from scratch and a set of demo data migrated in. Someone has to do this manually every day.
Hook required:
post-code-deploy
Filename:
rebuild.sh
File Location:
hooks/dev/post-code-deploy
site="$1" target_env="$2" source_branch="$3" deployed_tag="$4" repo_url="$5" repo_type="$6" drush @$site.$target_env si--yes drush @$site.$target_env mi --group="demo_content"
2. Ensure all module database updates are run when new code is deployed.
Nightmare Scenario Avoided
Module updates have been deployed that require schema changes someone forgets to run update.php after the code has deployed.
Hook required:
post-code-deploy
Filename:
updatedb.sh
File Location:
hooks/common/post-code-deploy
site="$1" target_env="$2" source_branch="$3" deployed_tag="$4" repo_url="$5" repo_type="$6" drush @$site.$target_env updatedb --yes
3. Sanitise your Production data whenever it's copied down to Stage or Development
Nightmare Scenario Avoided
You need to test our some changes to an e-commerce site using production data. However, you don't want customers to be emailed by accident and you don't want private data to be exposed.
Hook required:
post-db-copy
Filename:
sanitise.sh
File Location:
hooks/dev/post-db-copy
,
hooks/test/post-db-copy
site="$1" target_env="$2" db_name="$3" source_env="$4" drush @$site.$target_env sql-san -y
4. Clear Drupal caches when new code is deployed
Nightmare Scenario Avoided
You deploy some new code but it contains specific changes that require a cache clear. Will someone remember to do this?
Hook required:
post-code-deploy
Filename:
clearcache.sh
File Location:
hooks/common/post-code-deploy
site="$1" target_env="$2" source_branch="$3" deployed_tag="$4" repo_url="$5" epo_type="$6" drush @$site.$target_env cc all
5. Clear Varnish caches when new code is deployed
Nightmare Scenario Avoided
You deploy some new code but some of your site is cached by the Varnish servers. Developers are all logged in and don't notice - but the client is anonymous and wonders where all the changes are.
Hook required:
post-code-deploy
Filename:
clear-varnish.sh
File Location:
hooks/common/post-code-deploy
site="$1" target_env="$2" source_branch="$3" deployed_tag="$4" repo_url="$5" repo_type="$6" drush @$site.$target_env ac-domain-purge <your-domain></your-domain>
6. Reindex search when a new database is deployed
Nightmare Scenario Avoided
You update the production database, but the Solr Search has old data. Will someone remember to reindex the site?
Hook required:
post-db-copy
Filename:
reindex.sh
File Location:
hooks/prod/post-db-copy
site="$1" target_env="$2" db_name="$3" source_env="$4" drush @$site.$target_env solr-index-delete drush @$site.$target_env solr-mark-all drush @$site.$target_env solr-index
7. Turn off search indexing when copying production database to test
Nightmare Scenario Avoided
You copy down the production database to run some tests, test data is indexed to the production Solr cluster unless you tell Solr to go into read only mode. Will someone remember to do this?
Hook required:
post-db-copy
Filename:
disable-index.sh
File Location:
hooks/dev/post-db-copy
,
hooks/test/post-db-copy
,
site="$1"
target_env="$2"
db_name="$3"
source_env="$4"
drush @$site.$target_env apachesolr_environment_variable_set('<your-search-environment-name>', 'apachesolr_read_only', TRUE);</your-search-environment-name>
8. Turn off Developer modules in production
Nightmare Scenario Avoided
You have finished working on your site and are ready to launch so you copy the staging database up to production. Did anyone remember to turn of Devel, Views UI etc? Think of your Insight score!
Hook required:
post-db-copy
Filename:
devel-off.sh
File Location:
hooks/test/post-db-copy
,
hooks/prod/post-db-copy
,
site="$1" target_env="$2" db_name="$3" source_env="$4" drush @$site.$target_env dis views_ui -y drush @$site.$target_env dis devel -y drush @$site.$target_env dis dblog -y drush @$site.$target_env en syslog -y drush @$site.$target_env dis devel -y
9. Backup the database after a code deploy
Scenario
You deploy new code to production it's just a little change so let's not worry too much about backing up the data first...
Hook required:
post-code-deploy
Filename:
backupdb.sh
File Location:
hooks/common/post-code-deploy
site="$1" target_env="$2" source_branch="$3" deployed_tag="$4" repo_url="$5" repo_type="$6" drush @$site.$target_env ac-database-instance <your-database-name></your-database-name>
10. Prevent Test user accounts from ending up on the Production site.
Nightmare Scenario Avoided
You've completed the site build and push the data up to production - however there are multiple test users left behind with privileges to the site.
Hook required:
post-db-copy
Filename:
disable-testers.sh
File Location:
hooks/prod/post-db-copy
,
site="$1" target_env="$2" db_name="$3" source_env="$4" drush @$site.$target_env ucan <testusername1> drush @$site.$target_env ucan <testusername2></testusername2></testusername1>
There are plenty of tricks you can use Cloud Hooks for - let us know if you have any more useful ones!
