June 20, 2013

Seed 1.0: Drupal development server management

Branches

The biggest feature to land since the initial release of Seed is support for a Git branching workflow. A common scenario in the Seed workflow is to have multiple people working on a project, each with their own copy of the project's code but sharing a database so content and configuration is consistent. However, consider the following (simplified) scenario:

  • John and Jane are working on the same project, with a common database but each with their own checkout of the code.
  • John installs a new module which creates a block automatically, clears the site's cache and places the block in a region with Drupal's blocks administration.
  • Shortly thereafter Jane reloads a page. Since she doesn't have the new module John has installed, Drupal removes references to it from the database, including the block configuration.
  • John no longer sees the block in the region he just configured. In fact, he can no longer find the block on the block administration page.

This scenario is one we've encountered a lot in our development workflow. Generally it would require the person adding a new hook to commit the new code and for others to pull it, then clear caches. It also closely resembles a workflow known as Feature Branches, whereby new functionality is developed partially in isolation and then merged back in to the main branch.

In Seed we've now got some basic support for this workflow. We're introducing a new feature-branch command which will take a branch name, and create corresponding Git branch as well as a database where you can implement hooks or try out new modules in isolation without worrying about someone else overwriting your new functionality.

When you're ready, merging is also a single command: merge-branch. This will attempt to merge your branch in to the master branch, and if successful will optionally delete your branch and the cloned database.

Unfortunately we're still subject to Drupal's insistence of keeping configuration and content in the database, at least until Drupal 8, so any configuration or content created as part of your branch will have to be manually migrated or recreated on the "master" database. This is still an area we'd like to improve upon with Seed.

Other Improvements

There's been a number of other improvements, changes and bug fixes that have made their way in to Seed.

Folder structure

Previously we had a fairly strict folder structure based on our previous experience of how we'd lay out a project. After some consideration here at Fuse we've decided, internally, the change the way we lay out our projects. As a result, we've made file and folder paths more flexible and configurable.

Documentation

Seed has a lot of commands (with this release we're up to 30) and it's not always easy remembering what each one does and the arguments they take. To help ease this, the command line documentation has been vastly improved. Running seed with no additional arguments lists all commands with a description of each (the same as running drush help --filter=seed, also note we've improved a lot of the command aliases). If you'd like more information on a particular command, running seed commands will also list all the commands provided by Seed, but with the ability to choose a command which will then return all the arguments supported by the command as well as an example usage of the command.

Using Seed

With the work that's gone in to Seed in the last few weeks, we're tagging a proper 1.0 1.0.1 release. If you have any questions regarding the installation or use of Seed, or you'd like to additional functionality added, please don't hesitate to open an issue against the Seed repository.