Actualizar extensiones AL sin parar producción

Actualizar una extensión AL en un entorno de Business Central que la empresa utiliza cada día genera, con razón, bastante respeto. Una actualización mal planteada puede bloquear la sincronización de esquema, dejar datos a medias o forzar una parada en horario laboral. La buena noticia es que, con un método ordenado, la inmensa mayoría de las actualizaciones se despliegan sin que los usuarios lo noten. En este artículo repasamos el proceso que recomendamos en IJG Consulting.

1. Entender qué ocurre al actualizar una extensión

Cuando se publica una nueva versión de una extensión, Business Central realiza dos operaciones distintas: la sincronización del esquema (tablas y campos en la base de datos) y la actualización de datos (código de upgrade). Separarlas mentalmente es clave, porque los riesgos son diferentes: la sincronización puede fallar por cambios de esquema incompatibles, y el upgrade de datos puede fallar por lógica incorrecta o por datos inesperados en producción.

En entornos on-premises este flujo es visible en los cmdlets de PowerShell: Publish-NAVApp, Sync-NAVApp y Start-NAVAppDataUpgrade. En SaaS, la plataforma los ejecuta por usted al desplegar desde la página Gestión de extensiones o desde el centro de administración, pero la lógica es la misma.

2. Antes de tocar producción: sandbox y datos realistas

La regla de oro es no probar nunca por primera vez en producción. Cree un entorno sandbox como copia del entorno de producción, de modo que el upgrade se ejecute contra datos reales (volumen, valores atípicos, registros antiguos). Un upgrade que funciona con la base de datos de demostración puede fallar con diez años de histórico.

Lista de comprobación previa

Incremente la versión en el archivo app.json; Business Central solo actualiza a una versión superior. Compruebe las dependencias y el orden de actualización si otras extensiones dependen de la suya. Revise los cambios de esquema pendientes y confirme con el cliente la ventana de despliegue, aunque no prevea parada.

3. Cambios de esquema que no rompen producción

Muchas paradas innecesarias nacen de cambios de esquema destructivos. El modo de sincronización por defecto, Add, solo admite cambios aditivos: nuevos campos, nuevas tablas o nuevas claves. Si necesita eliminar un campo o una tabla, hágalo en dos fases:

Primera versión: marque el elemento como obsoleto con ObsoleteState = Pending, indique ObsoleteReason y ObsoleteTag, y migre los datos al nuevo destino. Versión posterior: cuando todos los entornos hayan migrado, pase a Removed. Evite el modo ForceSync salvo que sepa exactamente qué datos va a perder, porque fuerza la sincronización aunque haya cambios destructivos.

4. Código de upgrade idempotente

La migración de datos va en un codeunit con la propiedad Subtype = Upgrade. Los triggers principales son OnCheckPreconditionsPerCompany, OnUpgradePerCompany y OnValidateUpgradePerCompany, con sus equivalentes PerDatabase para datos que no dependen de la empresa. Aproveche la fase de comprobación previa para detenerse con un mensaje claro si falta algún dato imprescindible, antes de modificar nada.

Dos prácticas que evitan sorpresas: use las etiquetas de upgrade (codeunit Upgrade Tag, con HasUpgradeTag y SetUpgradeTag, y registrándolas mediante el evento OnGetPerCompanyUpgradeTags) para que cada bloque de migración se ejecute una sola vez, y utilice DataTransfer en lugar de bucles registro a registro cuando migre grandes volúmenes, porque reduce de forma notable el tiempo de ejecución.

5. Despliegue en producción y plan de vuelta atrás

Con el sandbox validado, el despliegue en producción debería ser una repetición del mismo procedimiento. En SaaS, las extensiones por inquilino se cargan desde Gestión de extensiones y se supervisa el resultado en el estado de despliegue de extensiones. Recuerde que la publicación directa desde Visual Studio Code es para sandbox, no para producción.

Defina antes de empezar cómo volverá atrás si algo falla. En SaaS puede restaurar el entorno a un punto anterior en el tiempo desde el centro de administración; en on-premises, haga copia de seguridad de la base de datos antes de sincronizar. Un plan de reversión escrito y probado convierte una incidencia en una molestia menor.

6. Después del despliegue

Verifique que la versión instalada es la esperada, revise el registro de errores de upgrade, ejecute un conjunto breve de pruebas funcionales con el usuario clave (un pedido, un albarán, un informe) y deje constancia de la versión desplegada y de la fecha. Si utiliza pruebas automatizadas, intégrelas en el proceso de publicación.

Errores frecuentes que conviene evitar

Los problemas que vemos con más frecuencia en proyectos reales son siempre los mismos: olvidar incrementar la versión y descubrir que no se aplica nada, eliminar un campo en la misma versión en la que se deja de usar, escribir un upgrade que solo funciona la primera vez y falla al reintentarse, o desplegar en el último momento sin haber probado con datos de producción. Todos se evitan con el procedimiento anterior y con una revisión de código antes de cada publicación.

Resumen del método

Pruebe primero en un sandbox con datos reales, haga solo cambios de esquema aditivos y retire elementos en dos fases, escriba upgrade codeunits idempotentes con etiquetas, despliegue en una ventana acordada y prepare siempre la vuelta atrás. Con este método, actualizar extensiones deja de ser un evento de riesgo para convertirse en una tarea rutinaria.

¿Necesita ayuda con sus extensiones AL?

En IJG Consulting actualizamos y mantenemos extensiones AL para empresas y Partners Microsoft en España y Europa. Si quiere revisar su caso, reserve una reunión de 30 minutos o escríbanos a info@ijgconsulting.com.