Mettre à jour un module sans casser les boutiques : scripts d'upgrade et versionnage
L'installation propre, tout le monde la teste ; la mise à jour depuis la version d'il y a un an, presque personne. Voici comment nous évitons qu'une nouvelle version casse des boutiques qui fonctionnaient.
Quand on teste un module, on l'installe généralement sur une boutique vierge. Mais vos clients n'installent pas : ils mettent à jour, en sautant parfois cinq versions. Si le chemin de mise à jour n'est pas soigné, la nouvelle version fonctionne sur votre machine et échoue sur la leur.
Comment PrestaShop décide quoi exécuter
Lors de l'envoi d'une nouvelle version, PrestaShop compare la version enregistrée dans la table module avec celle du code et exécute, dans l'ordre, les fichiers upgrade/upgrade-X.Y.Z.php dont la version se situe entre les deux. Chacun définit une fonction :
function upgrade_module_1_4_0($module)
{
$db = Db::getInstance();
$existe = $db->executeS("SHOW COLUMNS FROM `" . _DB_PREFIX_ . "mimodulo` LIKE 'fecha_envio'");
if (!$existe) {
$db->execute("ALTER TABLE `" . _DB_PREFIX_ . "mimodulo` ADD `fecha_envio` DATETIME NULL");
}
return $module->registerHook('actionOrderStatusPostUpdate');
}
Les quatre règles
- Idempotents. Un script peut s'exécuter deux fois (une mise à jour interrompue, une réinstallation). Vérifiez avant de créer : colonnes, index, onglets, configurations.
- Tout ce qui est nouveau, aussi dans l'upgrade. Les hooks, onglets, tables et valeurs de configuration que vous ajoutez dans
install()doivent avoir leur jumeau dans un script d'upgrade, sinon les anciennes boutiques ne les auront jamais. - Ne supprimez jamais les données du client. Si une colonne est en trop, laissez-la ou renommez-la ; ne la supprimez pas dans un upgrade. Et attention à la désinstallation pour réinstaller : certains modules suppriment toutes leurs tables à la désinstallation.
- Renvoyez vraiment true ou false. Si l'upgrade échoue et que vous renvoyez
true, PrestaShop marque la version comme appliquée et ne réessaiera pas.
install() et qu'un upgrade ultérieur le recréait sans vérifier. Doctrine attend une ligne et en trouve deux.Versionnage sémantique
- Correctif (1.4.1) : corrections sans changement de données.
- Mineure (1.5.0) : nouvelles fonctionnalités rétrocompatibles, avec leur script d'upgrade.
- Majeure (2.0.0) : changements qui imposent de revoir la configuration ou qui abandonnent des versions de PrestaShop ou de PHP.
Comment nous testons
Nous installons la version précédente publiée sur une boutique de test, nous la configurons avec des données proches de celles d'un client, puis nous mettons à jour avec le nouveau ZIP depuis le gestionnaire de modules, exactement comme le fera le client. Ce n'est qu'ensuite que nous testons l'installation propre. Cela paraît plus long ; en réalité, c'est ce qui nous épargne les incidents du lundi matin.