CI/CD en Business Central: contexto actual y estrategia de Microsoft
La comunidad de desarrolladores de Dynamics 365 Business Central debate hoy con más intensidad que nunca sobre DevOps y CI/CD. Microsoft ha reorientado por completo su estrategia de herramientas de pipeline hacia AL-Go for GitHub, ha confirmado el fin de soporte de BcContainerHelper para el 1 de octubre de 2027 y ha dejado claro que ya no entregará nuevas herramientas de CI/CD para AL en Azure DevOps.
Este giro estratégico plantea una pregunta que muchos equipos se hacen ahora mismo: ¿debe todo proyecto de Business Central adoptar DevOps? ¿O hay escenarios donde tanta automatización no compensa? Analicemos las novedades y sus implicaciones reales.
AL-Go for GitHub: la apuesta de Microsoft para DevOps en Business Central
Fin de BcContainerHelper y transición a GitHub
El mensaje de Microsoft es inequívoco: el esfuerzo oficial en herramientas DevOps para AL se concentra en GitHub. Ambas plataformas (Azure DevOps y GitHub) siguen soportando pipelines para AL, pero Microsoft ha declarado que sus futuros compromisos van dirigidos a AL-Go for GitHub.
En la práctica, esto implica que no llegarán nuevas herramientas oficiales de Microsoft para desarrollo AL en Azure DevOps; quienes deseen permanecer en esa plataforma deberán construir sus propios pipelines o recurrir a soluciones de terceros como ALOps.
En abril de 2025, Freddy Kristiansen (contributor principal del proyecto) abrió un issue en el repositorio oficial de navcontainerhelper confirmando que BcContainerHelper dejará de tener soporte el 1 de octubre de 2027. En ese mismo anuncio, Microsoft recomienda explícitamente a los partners usar AL-Go for GitHub u otra solución DevOps gestionada en lugar de mantener pipelines propios basados en BcContainerHelper.
Para quienes llevamos años orquestando builds con scripts PowerShell y contenedores manuales, esto marca un antes y un después: la herramienta que era la columna vertebral de muchos pipelines tiene fecha de caducidad.
Un dato relevante: más de 500 partners ya utilizan AL-Go for GitHub, según indica Microsoft en la discusión pública del issue7. No estamos ante una herramienta experimental.
Qué es AL-Go y cómo funciona en proyectos AL
AL-Go for GitHub es un conjunto de plantillas y acciones de GitHub diseñadas para proyectos AL, tanto extensiones PTE (Per Tenant Extension) como aplicaciones de AppSource. Su propuesta es que configurar integración y entrega continua sea casi plug-and-play, sin conocimiento previo de canalizaciones, Docker ni PowerShell9. Microsoft busca con ello que «más partners adopten estas prácticas, elevando la calidad de las aplicaciones de Business Central».
Funcionalidades clave de AL-Go for GitHub
- Creación de apps desde flujos de trabajo: Se puede generar una nueva app o test app a través de workflows predefinidos, o agregar una existente cargando el archivo .app al flujo «Agregar aplicación existente».
- CI/CD automático: Las aplicaciones agregadas al repositorio se incluyen automáticamente en el flujo de CI/CD. La ejecución de pruebas y los informes se controlan de forma automática para todas las apps de prueba.
- Artefactos y releases: Cada compilación exitosa produce artefactos almacenados durante 90 días (período predeterminado de GitHub). Las releases se almacenan de forma indefinida, junto con la fuente de la versión.
- Despliegue a entornos: Un entorno de cliente se puede vincular al repositorio de GitHub para implementación continua o manual14.
- Entornos de desarrollo: Permite crear entornos de desarrollo locales basados en Docker y entornos SaaS online con todas las aplicaciones publicadas previamente, listos para desarrollo rápido.
- Automantenimiento: El flujo «Actualizar archivos del sistema AL-Go» garantiza que los repositorios usen siempre la última versión de los workflows y acciones, evitando que queden obsoletos.
En cuanto al rendimiento de los pipelines, la discusión pública ofrece datos concretos: cada workflow tarda entre unos pocos minutos y 15 minutos, dependiendo de la configuración El escenario más lento (15 minutos) corresponde a GitHub hosted runners con contenedores, sin caché; el más rápido (pocos minutos) utiliza GitHub hosted Linux runners con compilerfolders y caché de artefactos.
Esto ha generado debate: algunos desarrolladores consideran que 15 minutos para una compilación sin tests es un orden de magnitud demasiado lento, comparando con los 30–70 segundos que se logran con un compilador instalado/cacheado en un agente Windows local18. Microsoft ha indicado que seguirá trabajando en mejorar el rendimiento precisamente por la base de más de 500 partners activos.
Beneficios de DevOps y CI/CD en Business Central
El artículo «Is DevOps a Must for Your Business Central Project?» publicado por DynaExperts en septiembre de 2025 sistematiza lo que DevOps aporta al ecosistema BC20. Los beneficios principales son:
| Capacidad | Description |
| Integración continua (CI) | Compilaciones automatizadas, análisis de código (CodeCop, AppSourceCop) y ejecución de tests en cada cambio |
| Entrega continua (CD) | Promoción automatizada de apps entre entornos |
| Cumplimiento y estándares | Validación técnica para AppSource y refuerzo de calidad de código |
| Future-Proofing | Validación contra versiones Next Major de BC para identificar breaking changes con antelación |
| Colaboración | Pull requests, estrategias de branching y revisiones de código para equipos multi-desarrollador |
Para ISVs y proyectos grandes de partners, estas capacidades se traducen en menor riesgo, calidad consistente y ciclos de release más rápidos.
Desventajas y costes de implementar DevOps en Business Central
Sin embargo, el coste de configuración y mantenimiento no puede ignorarse. El mismo artículo de DynaExperts identifica estos factores de sobrecarga:
- Infraestructura: Los pipelines de Business Central dependen de contenedores Windows, que consumen recursos significativos de disco y memoria. Para proyectos pequeños, esto puede resultar desproporcionado.
- Curva de aprendizaje y mantenimiento continuo: Comprender las actualizaciones de contenedores, los fallos de pipeline y los cambios venideros (como la retirada de BcContainerHelper en AL-Go prevista para 2027) requiere inversión continua.
- Impacto en la velocidad de entrega: En proyectos pequeños de un solo desarrollador, los procesos DevOps pueden retrasar la entrega, haciendo que la solución parezca menos ágil ante el cliente.
- Costes reales: Aunque las licencias son modestas —Azure DevOps Basic es gratuito para hasta 5 usuarios y GitHub Actions ofrece niveles gratuitos—, el coste real es tiempo, tiempo que podría dedicarse a generar valor directo.
Cuándo usar DevOps en Business Central según el tipo de proyecto
La clave no es «DevOps sí o no», sino dimensionarlo correctamente según el proyecto. La siguiente tabla resume los criterios:
| Scenario | ¿DevOps completo? | Justificación |
| App ISV / AppSource | Sí, imprescindible | Validación automatizada, empaquetado y envío a AppSource casi obligatorios |
| Proyecto multi-desarrollador | Yes | Control de versiones, PRs, testing automatizado previenen conflictos de código |
| Solución de larga vida o regulada | Yes | Garantiza trazabilidad, cumplimiento de auditoría y actualizaciones suaves |
| Múltiples clientes/tenants | Yes | Los pipelines garantizan consistencia entre entornos |
| Personalización puntual para un solo tenant | Probablemente no | El overhead puede superar el beneficio |
| Un solo desarrollador, alcance limitado | Valorar caso a caso | La inversión puede no justificarse si el ciclo de vida es corto |
| Prueba de concepto o mejora temporal | No | Priorizar velocidad y coste sobre proceso formal |
En los casos donde DevOps completo resulte excesivo, el overhead de mantener un pipeline full CI/CD puede pesar más que sus beneficios.
DevOps a medida: enfoque práctico para Business Central
DevOps «a la medida»: el punto intermedio pragmático
Para proyectos pequeños o de un solo desarrollador, DynaExperts propone lo que denomina «Right-Sized DevOps»: un conjunto de prácticas mínimas pero disciplinadas que aportan orden sin la carga de una automatización total:
- Git con pull requests (aunque sea auto-revisado): tu yo del futuro agradecerá un historial claro de cambios.
- Análisis estático local con CodeCop para mantener disciplina de código.
- Un único workflow de CI para validación de build: garantiza que lo que está en el repo realmente compila.
- Despliegues manuales, pero siempre usando los artefactos generados por CI, asegurando que lo probado es idéntico a lo implantado.
- Versionado semántico y notas de release documentadas, por sencillas que sean.
Este enfoque asegura trazabilidad y calidad sin ralentizar la entrega. Si el proyecto crece, siempre se puede ampliar el pipeline de forma incremental.
Tendencias: IA, Copilot y evolución del desarrollo en Business Central
La presión sobre la calidad y la compatibilidad del código no hace más que aumentar. Varios factores del ecosistema refuerzan la necesidad de prácticas DevOps sólidas:
Eliminación masiva de objetos obsoletos en la versión 26
Microsoft ha anunciado que, a partir de la versión 26 de Business Central, se eliminarán aproximadamente 150 tablas y más de 1.000 campos que estaban marcados como en desuso. Esto afecta a tablas de gestión financiera antigua, campos obsoletos en inventario y producción, y funciones en desuso del propio código base.
Para los desarrolladores, la implicación es directa: toda extensión personalizada que dependa de estos elementos debe adaptarse, y un pipeline que compile contra la Next Major detectaría estas roturas con antelación. Además, se ha puesto fin a la migración directa desde versiones anteriores a la 14, obligando a actualizaciones progresivas en varias fases.
Nuevas capacidades de desarrollo en la oleada 2 de 2025
La plataforma sigue evolucionando con novedades que impactan al flujo de trabajo diario del desarrollador: la posibilidad de cancelar la compilación y publicación desde Visual Studio Code (disponible desde octubre de 2025), un nuevo método AL para truncar datos de tabla, visualización de información de llamadas SQL en perfiles de rendimiento y mejoras en la herramienta de scripting de página. Cada una de estas funciones altera cómo trabajamos y qué podemos automatizar.
Herramientas para desarrolladores en 2026
Según el análisis de LLB Solutions, la plataforma avanza hacia una integración completa con GitHub para control de versiones, Page Scripting y frameworks de prueba para extensiones y agentes, y mejor soporte para construir soluciones sobre Copilot. Todo apunta a un ecosistema donde el desarrollo «artesanal» sin pipeline queda cada vez más lejos del estándar.
El factor IA
Business Central incorpora agentes autónomos que ejecutan tareas repetitivas —desde la entrada de datos hasta la revisión de documentos— y un Payables Agent capaz de leer facturas en PDF y sugerir registros contables de forma automática. Para los desarrolladores, esto implica nuevos puntos de integración y prueba que se benefician enormemente de pipelines automatizados; la complejidad del código que debemos mantener y testear no deja de crecer.
Cómo adoptar DevOps en Business Central de forma inteligente
Ser desarrollador senior de Business Central en 2026 implica dominar no solo AL y la lógica de negocio, sino también los procesos de entrega. Microsoft lo facilita al punto de que ya no hay excusa técnica para no tener al menos CI básico: AL-Go busca que la integración continua sea «prácticamente gratuita en inversión»58 y que los partners puedan configurarla sin conocimiento previo de canalizaciones, Docker ni PowerShell.
Aun así, la respuesta correcta no es «DevOps para todo a cualquier coste». Como hemos visto, la discusión en la comunidad ya no gira en torno a «¿Debo adoptar DevOps?» sino a «¿Cómo lo dimensiono inteligentemente según mi proyecto?». La estrategia más efectiva consiste en adoptar un «DevOps a medida» que alinee las prácticas con la escala, complejidad y longevidad de cada proyecto. Sobredimensionar puede erosionar la competitividad; quedarse corto puede comprometer la mantenibilidad.
Si aún mantienes tus desarrollos con métodos completamente manuales, este es el momento de explorar estas herramientas. Puedes empezar creando un repositorio en GitHub basándote en las plantillas oficiales de PTE o AppSource de AL-Go y configurar un pipeline básico de compilación. Notarás pronto la diferencia en tranquilidad y consistencia.
Y tú, en tu experiencia con Business Central: ¿ya abrazaste AL-Go u otra automatización, o sigues pensando que «si algo funciona, mejor no tocarlo»? ¿Cuáles han sido tus mayores obstáculos para implementar CI/CD en tus proyectos BC? Te invito a compartirlo y debatirlo: la mejor forma de aprender en comunidad es contrastando estas vivencias. ¡Espero tus comentarios!