Politiques de Koumbit reliées aux mises à jour (MAJ) Drupal et Aegir
Contents
Prérequis
Infrastructure
L'équipe de mises à jour prend en charge les contrats de mises à jour de sites en production hébergés dans une infrastructure Aegir/kPlatforms à la version la plus récente (ex.: Aegir.koumbit.net).
Les clients n'ayant pas cette infrastructure et voulant un contrat de MAJ sont invités à consulter l'équipe infra/sysadmin pour la mise en place de Aegir, puis à consulter l'équipe web pour la migration des sites vers une plate-forme standardisée avec kPlatforms.
Des mises à jour Drupal sans infrastructure Aegir/kPlatforms peuvent être négociées sous forme de banque d'heures de consultation et pris entièrement en charge par l'équipe web.
Version de Drupal
Un contrat de mises à jour ne peut plus être accomplit lorsque la version du core de Drupal n'est plus supportée par Drupal.org. Il faut alors contacter le client pour lui expliquer la situation et analyser les solutions (migration du core ou annulation du contrat).
Nomenclature des sites
C'est important d'avoir le nom canonique du site exactement comme l'URL principal auquel le site est accessible.
- Exemples:
- Dans Aegir, le site est "exemple.site.koumbit.net" avec un alias "exemple.org". Il faut s'assurer de migrer le site à "exemple.org" et, au besoin, y mettre l'alias "exemple.site.koumbit.net".
- Dans Aegir, le site est "exemple.org" avec un alias "www.exemple.org". Mais en réalité tout est redirigé vers "www.exemple.org". Il faut s'assurer de migrer le site à "www.exemple.org" et, au besoin, y mettre l'alias "exemple.org".
Ceci pour les raisons suivantes:
Cron peut avoir des problèmes à rouler: cron uses external command; cron only run if canonical hostname exists.
Lorsqu'on a un alias interne comme non canonique, mais que le site est public avec un autre URL, ça brise le flush de Boost, il ne flush pas correctement la cache (voir Clear the cache boost on verify (ex: after a migration/clone)).
- La recherche (/search) dans Aegir ne marche pas bien et on doit utiliser le nom complet du site pour le trouver.
- L'URL des fichiers sera plus "beau" avec le vrai nom de domaine.
- Un site aegir n'ayant pas son propre domaine porte à confusion sur son état de dev / staging / prod.
- Les différents alias devraient tous rediriger vers le domaine principal pour éviter d'avoir plusieurs sites web avec le même contenu, car c'est négatif pour le SEO.
Accomplissement
Horaire
Voir le Calendrier des MAJ.
Ce qui est mis à jour
Les modules, thèmes et librairies qui se trouvent dans "sites/all" seulement sont mis à jour. Les modules, thèmes et librairies dans les répertoires de sites ne sont pas mis à jour.
On vise l'utilisation des modules stables. Si un module a une version majeure supérieure qui est encore en dev, alpha, beta ou rc, on attend que celui-ci ait une release stable pour utiliser cette version. Par contre, on met à jour les versions mineures alpha, beta et rc s'il n'y a pas de release stable afin de suivre leur développement.
Exemples:
- On met à jour de "6.x-2.0-alpha1" à "6.x-2.0-alpha2"
- On ne met pas à jour de "6.x-1.0" à "6.x-2.0-alpha1"
- On met à jour de "6.x-1.0" à "6.x-2.0"
On peut toutefois décider de faire autrement pour corriger un bug ou utiliser des nouvelles fonctionnalités nécessaires.
Tests post mises à jour
Les tests post mises à jour sont effectués seulement sur les sites ayant un contrat de mises à jour.
Aegir.koumbit.net
Plates-formes de production
Critères pour qu'une plate-forme soit supportée en production sur Aegir.koumbit.net:
- Le core et les modules doivent êtres supportés par la communauté (maintenance de sécurité).
- Avoir un plan d'affaires de Koumbit pour ce service.
- Avoir un plan de support à Koumbit.
- Avoir au moins un client pour ce service.
Références:
Sites désactivés
Les sites désactivés (Disabled) qui se trouvent dans une plate-forme qui sera migrée et détruite seront eux aussi supprimés avec la plate-forme, puisqu'il n'est pas possible de migrer un site désactivé dans Aegir.