Main menu

You are here

Although it is (relatively) easy to use something like Jenkins for Continuous Integration with Drupal, you can create something of a dumbed-down budget version with just four commands:

svn update (or svn switch, or git equivalents)

drush updatedb -y

drush features-revert-all -y

drush cc all

To put that in plain English, this will:

update to the latest code base from SVN/GIT, etc

run any database updates in _update() functions

update to the latest version of any enabled features modules

clear all caches so that the latest feature changes are applied

The key to this is a disciplined use, and good understanding of features in Drupal 7. I usually try to use a number of relatively small, well-defined feature modules, rather than one over-sized one.

If you are just looking for a way of rapidly deploying in an automated, reliable and repeatable way, this may well be sufficient for you. If you need more CI-related features such as automated testing, code review, automated code documentation, etc. then you'll probably still need something like Jenkins.

Tags:

4 Comments

Nice short tutorial to deploy the things when you make them ready on your dev environment. But what about readying your dev environment? How do you recreate your features, etc? Do you use a module or a script?

I usually build my dev environment through a combination of contributed and my own custom modules, along with the various configurations I do through the Drupal admin screens. I then build a feature (or set of features) which contain all of these settings (or at least the ones that can be included in features - other settings would need to be added through _install() functions) and module dependencies. I usually have a master feature module which can be used to include all of the others.

On a good day, creating/deploying a new site involves merely installing the master feature module on top of a fresh Drupal installation using the code base created above.

Yes, you're right! And in reality, I tend to do this as an (at least) two step process. Step 1 involves running the tests (simpletest, and phpunit-based acceptance tests), coder review, PHP documenter, etc. Step 2 is what I describe above - which is really more like continuous deployment.