There's something in the air
There's a growing profusion of tools available for rapid Drupal deployment and to simplify testing and new development. These tools typically offer tight integration between version control and deployment, sometimes even automatically creating whole new environments when new git branches are created. There are hosted services such as
Even outside of the Drupal-specific toolset, there are other possibilities. Heroku recently expanded their php support making it a potentially attractive platform for Drupal sites. Redhat also offers a PAAS that they call Openshift.
Openshift already has a Drupal Quickstart package, but it's
not really suitable for production use. It replaces
drushrc.php on every build, and it's also
got no ability to use
drush make when building Drupal (so you can't
easily use anything but the default install profiles).
Nonetheless, I was intrigued by a fully open-source platform (Openshift
reasonably priced, scalable, builds on
git push, has Jenkins
integration available, and can get a Drupal site up and running in a
minute or two. I was also interested in being able to use the same
platform for non-Drupal sites, so I decided to rewrite Openshift's
For now, I'm concentrating on Drupal 7—though I can now officially give Drupal 8 a try. I'd note that this is definitely an experimental product and is a) not guaranteed to work, and b) may give your bicycle flat tires.
Disclaimers out of the way, please clone the repository from Github and try it out.
1 git clone https://github.com/ctorgalson/openshift-d7.git 2 cd openshift d7 3 rhc app create DRUPAL7TEST php-5.3 mysql-5.1 cron --from-code=https://github.com/ctorgalson/openshift-d7 -e ./.openshift/environment_variables
Set up git branches
Openshift will now have set up a new git repo for your app. You need to
push any changes to this repo in order to get Openshift to rebuild and
redeploy the site. To make this easier, add the Openshift git repo as a
new remote. To do this, run
rhc app app show -a DRUPAL7TEST and copy
Git URL output.
git remote add openshift plus the copied url. With this
basic method, it's also possible to have e.g. one or more different
environments, like dev, production and staging, each tied to a different
branch in git.
To do that, you'd need to set up three local branches in
production, and create three different
Openshift apps using the steps under Get started, above.
Maintenance (this is the worst part…)
One quirk about Openshift is that you can't manually push/pull or commit
changes on the remote site. This is good in a way—it encourages
developers not to make changes on production etc—but since there's
no running environment with a git repo, we can't just use
drush dl to
add new modules.
The original Openshift quickstart downloads Drupal + contrib on every build, and I haven't altered that in this project, though I have added the ability to use nonstandard install profiles and make files.
This means that we can download new modules by just adding them to a
make file, and it also means that we could use
drush up modulename or
drush updb to update new modules, but I wasn't happy with forcing a
database-related drush action on every build (since, i.e. many build
operations might involve code-only changes etc).
So instead, I've implemented a system that uses a textfile,
module_delta that looks something like this:
1 # This file should be relatively short, as the deploy action hook loops through 2 # it. If it contains one or more lines BEGINNING WITH 'update_modules:', 3 # 'enable_modules:', 'disable_modules:', or 'uninstall_modules:' followed by a 4 # space-delimited series of module names, the deploy action hook will run one or 5 # more of drush up, en, dis, or pm-uninstall as appropriate. 6 # 7 # At this time, the lines MUST occur in the order shown in the example below. 8 # 9 # Example (uncomment these lines to run drush up, en, dis, or pm-uninstall on 10 # deploy): 11 # 12 # update_modules: devel-7.x-1.x 13 # enable_modules: comment 14 # disable_modules: views_bulk_operations 15 # uninstall_modules: views_bulk_operations
The deploy hook script detects uncommented lines in this file beginning
uninstall_modules, and uses the appropriate drush command to perform
This method works. That said, it's not a fantastic workflow. As I see it, there are the following disadvantages:
- it's necessary to update both the make file and the
- to uninstall a module involves putting the module in the
disable_modulesline, running the build, and then moving the module to the
uninstall_modulesline, and running the build again