Actualizar un módulo sin romper tiendas: scripts de upgrade y versionado

Cuando pruebas un módulo, lo habitual es instalarlo en una tienda limpia. Pero tus clientes no instalan: actualizan, a veces saltándose cinco versiones. Si el camino de actualización no está cuidado, la versión nueva funciona en tu máquina y falla en la suya.

Cómo decide PrestaShop qué ejecutar

Al subir una versión nueva, PrestaShop compara la versión guardada en la tabla module con la del código y ejecuta, en orden, los ficheros upgrade/upgrade-X.Y.Z.php cuya versión esté entre las dos. Cada uno define una función:

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');
}

Las cuatro reglas

1. Idempotentes. Un script puede ejecutarse dos veces (una actualización interrumpida, una reinstalación). Comprueba antes de crear: columnas, índices, pestañas, configuraciones.
2. Todo lo nuevo, también en upgrade. Hooks, pestañas, tablas y valores de configuración que añades en install() deben tener su gemelo en un script de upgrade, o las tiendas antiguas nunca los tendrán.
3. Nunca borres datos del cliente. Si una columna sobra, déjala o renómbrala; no la elimines en un upgrade. Y ojo con desinstalar para reinstalar: hay módulos que borran todas sus tablas al desinstalarse.
4. Devuelve true o false de verdad. Si el upgrade falla y devuelves true, PrestaShop marca la versión como aplicada y no lo volverá a intentar.

Versionado semántico

• Parche (1.4.1): correcciones sin cambios de datos.
• Menor (1.5.0): funcionalidades nuevas compatibles hacia atrás, con su script de upgrade.
• Mayor (2.0.0): cambios que exigen revisar configuración o que abandonan versiones de PrestaShop o PHP.

Cómo lo probamos

Instalamos la versión anterior publicada en una tienda de pruebas, la configuramos con datos parecidos a los de un cliente, y actualizamos con el ZIP nuevo desde el gestor de módulos, exactamente como lo hará el cliente. Solo después probamos la instalación limpia. Parece más lento; en realidad es lo que nos ahorra las incidencias del lunes por la mañana.