Following on from the presentation at the Entice meeting in April, this document provides more details on the change management process for modules in the production environment. Change management of content is not covered here as this is site and workflow specific.
There are 4 types of modules in the CERN Drupal environment.
- Core modules which are included in the base Drupal distribution.
- Centrally Managed modules which are from drupal.org. These are modules which are used by a large number of sites and will be installed by default, although not enabled. Site administrators can then enable them as required. It is recommended that site owners use the centrally managed module rather than one of similar functionality from drupal.org.
- Entice modules are ones developed by the Entice community which are of general interest. Examples of this are the CERN profiles module, Indico, CDS, Phonebook. These will also be installed by default but not enabled.
- Site local which are modules that have been downloaded to the site by the site administrator.
This document applies to change management processes for Core, Centrally Managed and Entice modules. The Site local modules are managed entirely by the site administrator. The current list of modules in use is at module catalog
The change cycle will be based around the regular Entice meetings which occur approximately every month.
At the Entice meeting, a list of proposed module upgrades will be made for the Core, Centrally Managed and Entice modules. For Core and Centrally Managed, these changes will generally be to move to the latest production version on the drupal.org web site. For the Entice modules, this will be to deploy the latest production-quality versions as supplied by the developers. If there are objections to the proposed list of upgrades, these will be reviewed during the meeting and adjustments made accordingly.
During the week following Entice
On the wednesday following the Entice meeting, the key production sites will be cloned to a new site with -new extension. Thus, android.web.cern.ch would be cloned to android-new.web.cern.ch. This site would be a snapshot of the contents (database and files) and the latest module set as agreed in Entice meeting previously. An e-mail would be sent to the site owners to inform that the -new sites are now available. The sites can then be tested for the next three weeks to confirm that the new code does not cause issues. The -new sites should be viewed as sandboxes, any content created there will be overwritten. The snapshot and copy from production will be applied to all such sites automatically and without prior warning to the site administrators. These sites may also be subject to service interruptions as it is not guaranteed to be hosted on the same quality of infrastructure. If issues are discovered during the testing, they should be reported via the Entice web site forums. If there are pervasive problems with one of the modules, the upgrade of the entire module set will be postponed to the next Entice meeting where a revised set of modules will be presented. If a single site has an issue with one of the modules but other sites have no problems, that site can arrange to install a local copy of the existing version of the module so as to not be affected by the central change.
On the Wednesday following
The change to the module levels will be applied to all sites and a mail sent to the site owners to inform them when it is completed.
With this process, the responsibilities are split as follows The Drupal infrastructure administrators are responsible to
- Prepare the list of modules to be upgraded prior to the Entice meeting
- Organise the clone to the -new sites, upgrade the modules and inform the site administrators when this is completed
- Organise the upgrade of the production environments assuming no multi-site problems found
The site administrators are responsible for
- Reviewing the module list at or following the Entice meeting to raise any concerns on the planned content.
- Testing their sites once cloned to -new. If there are no comments from site administrators, the tests are assumed to be successful. If there are issues for single sites, the site administrator is responsible to install a local copy of the module at the necessary level locally on their site before the production upgrade is performed.
- Validating the production upgrade once completed
- Checking for security issues with any site local modules and performing the necessary upgrades.
Tim Bell on