I’ve gotten support issues from several clients that all revolve around a central theme: things need to happen differently on the development server than the live server and no one wants to manually change or configure anything. I’ve hacked together various solutions over the years and they always fall short in some way. Either they don’t work 100% of the time, or they’re too resource intensive, or they require too much manual intervention to be practical.
Recently, I’ve landed on a pretty solid workflow on Pantheon using Quicksliver. I won’t talk about Pantheon or the advantages that come with hosting and developing on their platform, you’re probably here because you already know. However, you may not know about Quicksilver.
Quicksilver is a relatively new part of Pantheon which allows for automating tasks and firing those tasks off before or after certain events on the Pantheon platform (pushing code, copying a database, flushing the cache…). Most of Pantheon’s examples are fairly trivial, and while they provide a good starting point for understanding the platform, they don’t really give you any best practices to follow or get you far in terms of something simple you can just drop into an existing site.
That’s what I’m going to give you!
First, the settings files. Yes, files. Strictly speaking you don’t need a settings.php file on Pantheon, but you do need one to use Drush, and you’ll want Drush available in Quicksilver. I’m establishing a best practice here in Rootid of creating a settings.dev.php, settings.test.php, and settings.live.php files and using the settings.local.php include pattern to bring in one of those values based on the PANTHEON_ENVIRONMENT constant. Note: I’m NOT using the $_ENV[‘PANTHEON_ENVIRONMENT’] variable, which doesn’t seem to be available in Drush. I want to do this because I want to create Quicksilver tasks that are 100% site independent. I want configuration to live in the site settings files, and the tasks to use those configurations instead of coupling configuration and tasks the way the examples do.
Breaking up your settings like this will allow you to easily define reusable settings files that you can just drop into a project. For my settings.dev.php I want to enable devel and disable Google Analytics, this is what my settings.dev.php looks like:
I’m adding an array to the $conf variable, qs_module_settings, and placing modules in the enabled/disabled array under it. I’ll define this in all three of my environment specific settings files. Now, I’ll create a Quicksilver task for enabling and disabling modules after the database is copied to an environment:
This task loads in the currently enabled and disabled modules, and the list of modules that should be enabled and disabled in the current environment. I want to note that I’m not doing a check to see which environment I’m in when I call this script. The assumption is that the settings file has made that call before this script was run. The correct values should be coming from the settings.<environment>.php file. This file should be saved to /private/scripts/update_modules/update_modules.php; the /private directory will prevent the script from being served to web users, the rest of the path is just to keep things clean.
Next, we need to create the pantheon.yml file to tell Pantheon that we want to enable Quicksilver and tell it about the service we’ve defined. The file is pretty self-explanatory, for more information than I could give here, check out the Pantheon Quicksilver docs. Place this file at the root of your site and it should be discovered when you commit it to your site:
Once all these files are in place push your code to Pantheon, copy the db from live to dev, and make sure your dev modules get enabled and the appropriate modules get disabled. Hopefully this help you on the path to a cleaner Pantheon workflow.
One more time I want to note that what I’m excited about with this setup is that the service being defined in update_modules.php is 100% independent of specific site configuration and as long as you always follow the same convention you can easily just drop it in to every site without modification.
Need help with implementation? Drop us a line »