Following on from our article on migrating to Drupal 9, we’re continuing our series of in-depth articles, today sharing our thoughts on the challenges of site factories.
Software development has evolved considerably over the last 20 years, moving from an artisanal to an industrialized mode of operation. This is particularly true of DevOps practices, where automation goes hand in hand with quality control. Ultimately, we’re trying to get closer to the world of traditional industry, where assembly-line production is fast and efficient.
To take this closer relationship with the industrial world a step further, the concept of site factories was born. At Digiwin, this concept has been successfully implemented based on the powerful Drupal CMS. Here, we present our work and experience, from our beginnings to our current site factory solution.
A quick reminder about Drupal
Drupal is a CMS (Content Management System). For the record, its name comes from the Dutch “Druppel” meaning “drop”, hence its logo.
Its original developer defines it as a fast website assembler that can be used as is on a web server. It can be used and customized in several ways, gradually becoming more complex, depending on the level of knowledge required:
- Out of the box: allows you to authenticate, manage revisions, create your own content types, menus, etc…
- Simple customization: simply drag and drop graphic elements to change their location, and change the look and feel of the site using a different theme, directly from the back office.
- Extend functionality by adding modules from the community
- Extend functionalities through in-house development, or by developing your own modules, which may or may not be shared with the community.
Drupal also features a hierarchy of substitutable functions, enabling experienced developers to rewrite part of the site’s operation without affecting the rest (hook system).
All this modularity allows a wealth of customization, but has a few shortcomings, notably its database model. Rather complex, it can contain several hundred tables, depending on the types of content created and modules used.
Defining a Multisite in Drupal
A multi-site installation allows a single Drupal instance (identical codebase) to serve several sites with different domain names. Each site has its own database and therefore its own settings, content, modules and activated themes.
In a multisite architecture, sites will often have a common base theme, and each site will be able to implement a specific sub-theme to personalize its look while retaining the main graphic lines defined in the base theme.
Like siblings, the sites in a multisite architecture may look and behave alike, or each may have its own style. They all share the same DNA.
Even so, site maintenance and upgrades can become complex and time-consuming, depending on the number of sites.
Even if version upgrades are less laborious thanks to Composer‘s dependency management, the core version upgrade will impact all sites at the same time. All sites will then go into maintenance at the same time.
What’s more, following a version upgrade, for major updates to the Drupal core, additional commands often need to be run. These are used to update the database structure, but it is generally impossible to run them on a large number of sites simultaneously.
All sites must then be tested for correct operation, and corrected if necessary, before going back online.
Definition of a Site Plant
The site factory concept is often confused with the multisite concept. As previously stated, multisite allows you to manage several sites with a single instance of the CMS platform.
The site factory, for its part, industrializes and even automates the creation and deployment of new sites.
Its main advantages are :
- Providing a common framework by harmonizing practices
- Reduce production costs at each site
- Reduce maintenance costs
- Share resources (maintenance, hosting, etc.)
Our first encounter with a Drupal site factory
Setting up a multisite with Drupal
Our first encounter with a Drupal site factory took place during an assignment at SNCF Réseau. Installed on a multisite basis, Drupal made it possible to deploy a large number of sites. The majority of these sites were dedicated to events (short lifespan, need for rapid implementation).
Several aspects proved tedious from the outset. Although this ecosystem of sites was presented as a site factory, in reality there were few automatic features. The majority of site creation actions were carried out by copying one of the existing site templates.
In addition, we were faced with another level of complexity linked to one of the drawbacks of multisite Drupal. As explained above, upgrading Drupal Core requires upgrading all sites. This entails a significant amount of work, sometimes with major problems to be solved due to non-compatible modules.
To avoid these inconveniences, the site factory consisted of several Drupal installations, one per version, with sites deployed on one or other of the versions. Upgrading consisted in migrating a site from one Drupal installation to another.
The solution is quite sensible. However, it does have a few drawbacks, particularly when it comes to modifying the basic templates, which must be done on every installation.
New direction: creation of a command tool in Symfony Console
To facilitate our management and reinforce the industrial aspect of the site factory, we have developed a command-line tool based on Symfony Console. In this way, the various stages from creation to online publication were automated.
This tool, which we called OXYGEN, was developed for Drupal 7 and then extended to site management in the Drupal 8 version:
- Duplicate a site (files, database, configuration)
- Add the new site to sites.php
- Add the vhost so that it can be accessed online via its own domain name
We’ve extended these features to other actions we used to do on a regular basis:
- Put into production from the recipe version
- Recover the production version of a local site for upgrading and debugging
- Archiving sites
- Site maintenance
The level of automation achieved was quite satisfactory, making our interventions efficient and productive. But then the customer expressed a new demand: to be autonomous for the creation of the simplest sites.
As OXYGEN is a command-line tool and therefore not aimed at the general public, it was not an acceptable solution for the customer. We therefore developed a specific module dedicated to this task.
Development of a Drupal 8 module in a D7 and D8 ecosystem
Our module is developed directly in Drupal 8. Because of the technological break with version 7 and the migration to D8 on almost all sites, developing a module in Drupal 7 with a Drupal 8 adaptation is unnecessarily costly. As we mentioned in an article, moving from D7 to D8 is far more complex than migrating from Drupal 8 to Drupal 9.
Installed on a specific site in the factory, this module performs the same actions as OXYGEN, but from a web interface.
This solution may seem ideal, and from a user’s point of view it was. But in reality, it is still subject to the technical maintenance shortcomings of the Drupal multisite. That’s why we started to imagine a site factory without the Drupal multisite, a solution we’re now using.
Our next article“Usine à sites Drupal: la version de la maturité” will explain how to use a Drupal site factory without multisite.
