Drupal 7 and Continuous Integration

Recently, I've published a bunch of testing-oriented articles on this blog. Of course, I must show you the higher purpose of these posts.

Continuous Integration (or CI) is a development process theory that intends to avoid the negative side-effects of the older waterfall release process. It's impossible for me to explain what CI is about, but Wikipedia and this book are a perfect start.

CI and Drupal

Features

Drupal is very reliant on its database system. Therefore it's advised that you develop in features. Features are a way to "export" almost anything you do manually. This includes site settings, content types, variables etc. - enabling the separation between content and configuration in Drupal. If you think about it, it's the cleanest way to develop your website, especially if you're working with a large team and with multiple environments. Another great advantage is that this pushes you into a workflow and you have to keep working in the same way all the time.

An exported feature looks like a module. This way you can add it to version control and version your Drupal website. Another advantage is that it's perfectly possible to build your site from scratch in a single Drush command once you use Install Profiles.

Here's a great video that introduces the concept of Features.

General Integration in Jenkins

Using this method it's now perfectly possible to integrate your code in a Continuous Integration environment like Jenkins. From there, you can trigger builds once the SimpleTests are run successfully. On your dev and test environment you can deploy continuously, while staging and production are e.g. deployed every time a sprint is finished.

Cucumber and Jenkins

Cucumber is able to export JUnit testing results and - when integrated correctly - attach video files to any job. When the build fails, the project manager or developer can instantly see where the test failed and come up with a solution for the problem. Hereby the whole team loses no time finding the error.

In reality

I wouldn't write this up, just because it looks nice in theory. At AUSY/DataFlow we have tested this and it's ready to be rolled out for our current projects. Soon I will inform you what problems we encountered and how we tackled them.

Remember that you can't always rely on these results. A large set of tests may give you a lot of confidence but there's always a false feeling of security. You're best to always keep your eyes open and thoroughly test your test/staging environment after deployment, but if you've done everything by the book, no major issues should pop up.