Drupal 7 tip: How to automate and control your go live checklist
This post will give you a list what to check when you go live with a drupal 7 website and how you can control it and automate it. You need to check this go live checklist each time you keep integrating new stuff during deployment to test if everything is still working. To save time this task can be automated.
When in development a lot of settings are turned off or are configured differently. Why? Because different environments might use different services and for some settings it is more convienent to develop with certain config. When going live you dont want your dev settings to be active. This post will explain how you can keep things under control and automate some parts of it so you dont have to check everything manualy every time.
Environment specific settings
Lets see which settings should be checked when deploying to test and live. Normaly when using a local - dev - test - live workflow, most of the local settings and dev settings should be the same and also most of test and live settings should be same. Since the client first checks the test version before going live the two environments should be the same except for the environment specific settings of course.
The easiest way to control settings is to keep a settings file per environment. In this settings file it is possible to set your environment specific settings. For example we can set following settings:
In settings.php (local/dev environment)
$conf['error_level'] = '2';
$conf['preprocess_css'] = '0';
$conf['preprocess_js'] = '0';
$conf['cache'] = '0';
$conf['page_compression'] = '0';
$conf['block_cache'] = '0';
In settings.php (test/live)
$conf['error_level'] = '0';
$conf['preprocess_css'] = '1';
$conf['preprocess_js'] = '1';
$conf['cache'] = '1';
$conf['page_compression'] = '1';
$conf['block_cache'] = '1';
So what we did was turn off error reporting, turn on preprocessing of css and js, enable page cache and enable block cache. These are some of the typical go live settings.
A typical site has some other environment specific settings depending on the functionality enabled. So one way to be sure your live settings stay the same is to keep them in the settings file. Note: this will make it impossible to change them in your live site.
$conf['so_env'] = 'local';
$conf['so_host_solr'] = '46.137.--.---';
$conf['so_port_solr'] = '8986';
$conf['so_path_solr'] = '/solr';
$conf['googlemap_api_key'] = 'ABQIAAAAfYxov8LBTzY0GIIX9zA54hS8rtsh0fmHD----------';
$conf['windows_live_login_client_id'] = '000000---------';
$conf['windows_live_login_client_secret'] = 'JMuzw----------------------------';
We have a site with a solr and have a different instance for all of our environments so we can fill in the settings here, we can do the same for our other env dependent settings like the maps api key etc...
Now all this is working just fine but what if you want to enable error reporting on the test instance? Some error is manifesting its self and you are not able to check it because you cannot change the setting. What this means is that this setting should not be configured the hard way in settings.php but you dont want to check this setting on every deploy you make.
Create a shell script and execute your shell script each time you deploy. This script, like your settings file will live in your version control system so you actualy keep track of your go live list.
An example of such a script can be:
drush vset --yes preprocess_css 1
drush vset --yes preprocess_js 1
drush vset --yes cache 1
drush vset --yes block_cache 1
drush vset --yes page_compression 1
drush vset --yes error_level 0
drush dis devel views_ui -y
drush dis update syslog dblog field_ui -y
drush cc all
#execute go live tests
drush test-run --uri=<a href="http://example.com/">http://example.com/</a> --xml=~/var/drupal/tests GoLiveTest
To use it create a file called update_live.sh. Make it executable chmod u+x update_live.sh and execute it ./update_live.sh
A you can see you will need drush (http://drupal.org/project/drush) to be installed on your webserver. Now you can still change these settings but each deploy they will be reverted to the settings for this environment.
You can use a CI server like Jenkins (http://jenkins-ci.org/) to automate this task. Each environment has its own script so you can actualy control how your site is deployed to each environment. What you can do is configure a job that excute a shell script each time you do a deploy. If you dont know how to setup drupal and jenkins stay tuned for later blog posts I will explain this.
The next thing you can do to automate the testing if everything is setup, is to run tests. Using the simple test module during deployment can verify a lot of things. Generaly it is not recommend to run tests against a live instance. But if you know what you are doing it can help you verify all your settings during deployment. Know what you are doing means:
- Make sure your tests dont cause any performance issues.
- Make sure you cleanup everything your tests are doing.
- Only test environment dependent functinality. All the other functionality you can test when deploying to dev - test
- Make sure you disable the simpletest module when done.
Note some settings are indeed hard to check using simpletest so this requires you to use some additional tools to monitor other parts of your infrastructure. You can decide for your self how far you want to go. Not everything should be automated, manual checking for some stuff is ok if it doesnt require you to do it often. If automating saves you time do it otherwise dont.
Here is the complete checklist of stuff we check when going live.
- Set Preprocessing js and css
- Set Page cache
- Set Block cache
- Set Page compression
- Set Error level
- Install PHP accelerator like APC etc
- Disable some core and contrib modules like for example update, syslog, dblog, field_ui, devel, views_ui, ... Logs and stats should be disabled you can use other tools on the server to monitor errors in a more performant way.
- Upgrade Drupal and the Contirb module to the Latest Version
- Schedule back up of database
- Protect Admin password
- Enable Google Analytics
- Use captcha or mollom for all forms
- Double check user registration settings.
- Double check all permissions.
- Check the watchdog for errors and warnings, and fix these
- Check input format
Use the drupal seo checklist to make sure everything is enabled as it should be. You can also check all settings using a script. (http://drupal.org/project/seo_checklist)
- Site SMTP settings
- Contact module settings, webform and/or others that require email.
Keep a list of test nodes. Typically when you build your instance you know what content is test content, so you can delete this or build your site without it.
- Run a link checker if it's an old/migrated site.
- Delete the .txt files (CHANGELOG.txt, COPYRIGHT.txt, INSTALL.mysql.txt, INSTALL.pgsql.txt, INSTALL.txt, LICENSE.txt, MAINTAINERS.txt, UPGRADE.txt) - See Securing access to files on your website for more about securing your site (http://technology.blue-bag.com/securing-access-files-your-website)
- Disable the default node front page (http://dominiquedecooman.com/blog/how-remove-drupal-default-node-page-ak...)
- Disable the search index when using solr (http://www.drupalcoder.com/blog/performance-tip-disable-drupals-core-sea...)
Set everything environment specific that doesnt require an occasional change in settings.php.
Set the other environment specific settings by a shell script each deploy.
Keeping both the script and different settings.php files ensure you can keep track of your go live requirements.
Use a golive simple test test to check if everything is working as it should be.
If you think of something else to check post it in the comments below and I will add it to the list.
Who are you?
By knowing who you are you will be directed to a page where we have displayed all our drupal services relevant to your professional identity.