Skip to main content

ANNOUNCEMENT - Mogdesign joins i-KOS Digital - click to read why...

You are here

10 Ways Acquia Cloud Hooks can help you sleep at night

Richard Jones's picture
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 fulfill 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 <your_profile_name> --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"
    repo_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>
 
 
## 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);
 
 
## 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>
 
## 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>
 
There are plenty of tricks you can use Cloud Hooks for - let us know if you have any more useful ones.
 

2 Comments

Comments

Chris Brookins (not verified)

These are great examples of the value Acquia Cloud hooks provide. Glad you're enjoying them to avoid your nightmare scenarios, and sleep better at night.

- Chris

Alex Bukach (not verified)

In fact Acquia runs that hooks only if you updates code, or copies db etc. from Acquia Workflow page only. They do not work if you just push commit/tag. See https://forums.acquia.com/acquia-products-and-services/dev-cloud/acquia-cloud-hook-post-commit

Add new comment