Drupal development as a team is tough: finding a balance between code and configuration saved in the database is one of the hardest challenges to overcome. When working in a team, it is even more important to control the development cycle, having different people work on different features at the same time, and automate as much as possible of the repetitive tasks you're really to do.
In this series, we'll look at the recipes we use at Marzee Labs to make Drupal development as a team a success. The very first ingredient, and the base of everything else: automating your build processes.
We'll start with Phing: an automation tool that replaces all your shell scripts and establishes a to-the-point development flow for your team.
Phing is a PHP build tool based on Apache Ant that does a great job of organizing tasks in targets, written using an XML-based syntax. For Drupal development, we find that using Phing gives us this extra layer on top of Drush to make building and testing Drupal sites so much easier.
Want to start developing a new feature and need a clean Drupal installation?
phing build is your answer. Need to change back to the master branch and work on a hotfix? Start with
phing build and you'll be sure to not mix configuration from the different branches.
Here are are the ingredients you need to get started with Phing and automate your Drupal development:
Enough theory? Let's have a look at a practical example: we'll clone MZ Box - our Phing boilerplate - and use this build a fully functional Drupal 7 site base on our MZ profile, which contains all our favourite modules, libraries and some settings to kick off your project.
$ git clone https://github.com/marzeelabs/mz_box.git $ cp build.properties.example build.properties
This clones the boilerplate repository and creates a new build.properties file which will hold all configuration specific for your project. You should create a new SQL database and update the database connection string in
Next, we're going to
make the project: Phing will take care of cloning the MZ profile, and calling
drush make to download all the modules and themes.
$ phing make
If all goes well, you'll read
You now have a full copy of Drupal core, the MZ installation profile, and contrib modules, libraries and themes in place. Now would be a good time to add all these files to the git repository and push them upstream to your new repository. Our first step is done!
Next, we'll want to install the site. If you look at
build.default.properties you'll see that
drupal.profile = mz so the
mz installation profile is the default profile that will be installed. We'll need to run
$ phing build
and - after a couple of minutes - you'll read again
BUILD FINISHED (note: you can see the entire build log on Travis ).
And voilà: you have a fully installed Drupal site. We've also added some goodies in the build target such as configuring a test editor account and adding a quick-switch for the Masquerade block so you can easily switch user accounts for testing.
You can run
phing build as much as you want to re-install the Drupal site, and keep a peaceful mind when developing new features.
If you analyze the phing
build target in the
build.xml file, you see that every build runs these targets:
For example, the
enable-dev-mode target activates development and UI modules and disables the Views cache:
<target name="enable-dev-mode" description="Configures this installation for use in development" depends="setup-phing-drush"> <!-- Enable development and UI modules --> <drush command="en" assume="yes"> <param>devel,views_ui,context_ui,field_ui</param> </drush> <!-- Disable views data caching --> <drush command="vset" assume="yes"> <param>views_skip_cache</param> <param>1</param> </drush> </target>
You can easily create new targets and have them depend on one another to automate common tasks. You can also run these targets independently. For example,
$ phing enable-dev-mode
will prepare your current sandbox for development, and
$ phing -l
will list all the available targets with a short one-liner to explain what the target does, which is great to communicate tasks to the other members of the team.
When adopting the git flow model, Phing is the missing link to re-build the site for a feature branch and developing features in isolation.
After switching to your feature branch, the only thing to do is run
phing build, work on your code and configuration (stored in code), push changes back upstream, and ask anyone in the team to review these changes by running
phing build on the feature branch.
Phing will establish a common language within the team and make it easy to share development recipes and best practices as documentable targets.
We've only scratched the surface of what you can do with Phing to automate your Drupal development. We use Phing to automatically migrate mock content using the Migrate module, run an automated test stack, and provide continuous builds everytime new code is pushed to the repository (check out our Travis logs).
The take home message is that building a Drupal site should be as easy as running
phing build, and with that - we've complied with the second step of Joel Spolsky's Joel Test to Better Code: "Can you make a build in one step?"
Featured image credit: Daniel Wehner / Flickr