While Acquia Site Factory is like a traditional Drupal multisite (one codebase, multiple sites), Pantheon’s model results in a unique codebase per site, with shared code in the custom upstream. While it is possible to consider each site as a standalone entity, I wanted to imitate Site Factory and use the upstream as the single code source for all sites.

The secret sauce to making this run fast is GNU Parallel, which executes commands in parallel rather than serially.

Routine maintenance and feature updates

My standard workflow is best for routine maintenance tasks like Drupal core and module updates, or theme and feature updates that can be installed automatically. All sites are updated in sync, from dev, to test, to live. This workflow has the highest level of automation and therefore lowest level of friction.

Image

Working on sites in batches

A batched workflow is sometimes needed for updates needing a lot of intervention, such as when content needs to be evaluated by a human or for updates that involve comprehensive or breaking configuration changes. I update sites in arbitrary groups—usually starting with simpler, low-risk sites and working up to more complex, higher-profile sites. This workflow is comprised of mostly manual processes and requires careful attention.

Image

Working on a single site

I use a focused workflow for tasks like building a new site or implementing a custom feature that impacts a single site. As with the other scenarios, I always deploy changes to all dev environments so I can evaluate the impact to the shared codebase. I deploy code for a single site to test—or even all the way to live—at many times throughout the sprint, sometimes multiple times in a single day. Once I’m satisfied with the code for that particular site, I roll it out to the rest of the fleet following a normal release process.

Image