Sector(s)

Visit the site

Visit the site

Organizations Involved

The group's Drupal site factory has more than 25 sites, managed by digital teams in several countries. Requests arrive continuously: fixes, new sites, larger projects. Parker+Parker runs application maintenance and projects in shared two-week sprints. Maintenance releases and feature releases each follow their own schedule, and some weeks have two releases. Every version ships with release notes and a test plan, and the client signs off before production.

About the project

Results

  • More than 300 requests created and more than 350 tickets resolved in six months.
  • 13 sprints and 32 versions shipped in six months, sometimes two releases in the same week.
  • Every version shipped with release notes and a test plan, then signed off by the client before production.

Goal

Keep more than 25 sites stable and evolving at the same time, for a decentralized organization where each country submits its own requests.

Challenge

Because the code is shared, every release can affect the whole fleet. Maintenance must not block projects, and projects must not delay urgent fixes. The client needs to know in advance what ships, when, and how to test it.

Solution

  1. Shared two-week sprints. Sprint planning splits capacity between maintenance tickets and project work, with the client.
  2. Two release types. Maintenance releases and feature releases each have a fixed day. The ticket list is frozen the day before.
  3. Release notes and test plans. Each version states what ships, on which sites, and how to check it.
  4. Client sign-off. The client tests on staging and approves every production release.
  5. Separate staging environments. One for maintenance, one for projects: a project in progress never blocks a fix.
  6. Weekly workshops. A one-hour maintenance workshop sets priorities every week. Project workshops are prepared in advance: reworded needs, mockups, open questions.

What editors do without developers

Country teams publish and organize their content with the shared block library, and request a new site through a standard form. Developer time goes to fixes and features, not to routine content changes.

Why Drupal was chosen

All sites share the same Drupal codebase through Drupal core's multisite feature. A fix or a feature is built once, then delivered to every site that uses it. This is what makes a sustained release rhythm manageable for more than 25 sites. Drupal's configuration management moves changes from development to staging, then to production, in a controlled way. Security and minor releases, published regularly, fit into the maintenance calendar. Major versions, which are predictable, are planned as projects in the same sprints. Thanks to the large contributed module ecosystem, most maintenance work consists of updating and configuring shared modules rather than writing code.

Application maintenance of a Drupal site factory: two-week sprints, up to two releases a week, more than 300 requests created, more than 350 tickets resolved and 32 versions shipped in six months.

Technical Specifications

Key modules/theme/distribution used:

Why these modules/theme/distribution were chosen

Paragraphs powers the shared block library that country teams use to build pages without developers. Drupal Commerce runs the e-commerce features, maintained and released in the same sprints as the rest of the platform. Drupal core's multisite feature lets all sites share the same Drupal codebase.

Six rules for a predictable release rhythm: shared sprints, two release types, release notes, client sign-off, separate staging, weekly workshop.
A fixed release rhythm for more than 25 sites: maintenance and feature releases, 13 sprints and 32 versions in six months, a one-hour weekly workshop.