ALM y CI/CD de principio a fin en Dynamics 365 Customer Engagement

Resumen del artículo publicado en LinkedIn (en inglés). El enlace “Ver original” lleva al texto completo.

Por qué en Dynamics 365 el ALM importa todavía más

En un proyecto normal, el código es la fuente de verdad. En Dynamics 365 lo es una mezcla de código (plugins, PCF, web resources), metadatos (tablas, formularios, vistas) y configuración (referencias de conexión, variables de entorno, flujos), todo dentro de una solución. Si el proceso falla, no se rompe un build: se rompe un tenant.

Las piezas del proceso

• Entornos: Desarrollo → Build/Integración → Test/UAT → Producción. Solo el pipeline despliega en UAT y Producción, con copia de seguridad previa automática.
• Datos ofuscados: si se refresca Dev o Test desde Producción, se enmascaran los datos personales antes de dar acceso (RGPD).
• Ramas: trunk-based con ramas de release; feature/* por historia, hotfix/* para urgencias. Las políticas de rama obligan a pasar el build, a tener revisores y a vincular un work item.
• Trazabilidad: historia de usuario → rama → PR → build → release → Producción, enlazado por el ID del work item. Con Definition of Ready y Definition of Done.
• Pull requests: revisión técnica y funcional, Solution Checker y escáner de secretos como requisito.
• Solución desempaquetada en el repositorio (pac solution unpack): no gestionada en Dev y gestionada en todo lo demás.
• Pipelines: CI valida build y Solution Checker en cada PR; CD promueve por etapas con aprobaciones e inyecta variables de entorno y referencias de conexión por entorno, sin editar nada a mano.

La lista de comprobación

Plan de vuelta atrás, gestión de secretos y monitorización posterior al despliegue definidos antes del go-live, no improvisados durante una incidencia.