Automatice los despliegues con la integración de Git de Dataverse y las canalizaciones de Power Platform

A medida que se escala la adopción de Power Platform, las organizaciones suelen tener problemas para mantener un modelo de desarrollo coherente y regulado en varios creadores, desarrolladores y entornos. Entre los desafíos comunes se incluyen entornos de desarrollo compartidos, rastreabilidad limitada de cambios, documentación de versión incoherente y dificultad para aplicar controles de ciclo de vida de desarrollo de software estándar en equipos de entrega de código bajo. Estos desafíos aumentan el riesgo de despliegue, ralentizan la colaboración y hacen que las actividades de auditoría y cumplimiento sean más difíciles de respaldar.

Esta arquitectura de referencia aborda estos desafíos al combinar la integración nativa de Git de Dataverse con canalizaciones en Power Platform, la gobernanza de Azure DevOps y la generación de notas de versión asistida por inteligencia artificial para crear un patrón repetible de gestión del ciclo de vida de aplicaciones empresariales (ALM).

Sugerencia

En este artículo se proporciona un escenario de ejemplo y una arquitectura de ejemplo generalizada para ilustrar cómo usar la integración de Git de Dataverse, las canalizaciones en Power Platform y Copilot Studio para automatizar las implementaciones y generar notas relacionadas. El ejemplo de arquitectura se puede modificar para muchos escenarios y sectores diferentes.

Diagrama de arquitectura

Diagrama de la estrategia de Dataverse ALM con la integración de Git en entornos de desarrollo, pruebas y producción mediante canalizaciones en Power Platform.

Flujo de trabajo

En los pasos siguientes se describen los flujos de trabajo de desarrollo, prueba, producción y revisión que se muestran en el diagrama de arquitectura.

Flujo de trabajo de desarrollo y control de código fuente

Los creadores y desarrolladores usan uno de varios entornos de desarrollo de Dataverse para realizar cambios. Además de un entorno de desarrollo principal, los equipos pueden usar otros entornos, por ejemplo, para desarrolladores júnior, recursos externos, trabajo en curso de iniciativas a largo plazo u otros trabajos que los equipos no deban promocionar automáticamente a la ruta principal hacia producción.

  1. Asigne cada flujo de desarrollo a un entorno de Git o a una rama de características.

  2. Sincronice los cambios en Git a través de la integración de Git de Dataverse.

  3. Revise las ramas de características y combínelas en la rama principal de Git mediante solicitudes de extracción y directivas de protección de ramas, cuando estén listas para enviarse a la ruta ALM de pruebas de producción.

  4. Para evitar la desalineación de funcionalidades, incorpore en las ramas correspondientes a todos los entornos de desarrollo los cambios aceptados en la rama principal.

  5. Asegúrese de que la rama principal pase a ser la fuente autorizada para la integración y la promoción de versiones.

Flujo de trabajo de prueba y validación

  1. Desde la rama principal, use un anfitrión personalizado de canalización para promover la solución empaquetada al entorno de prueba, directamente desde el código fuente de la rama principal mediante el tipo de implementación de control de código fuente.

  2. Use el entorno de prueba para la validación técnica, las comprobaciones de integración y las pruebas de humo.

  3. Después de la validación, promueva la solución al entorno de prueba de aceptación del usuario (UAT) mediante canalizaciones en Power Platform. Cree o actualice la rama de versión correspondiente en Git desde la rama principal.

  4. Generar notas de la versión a partir de los elementos de trabajo de DevOps en estado UAT y distribuirlas a los responsables de pruebas de UAT. Use un agente de Copilot Studio para generar y dar formato a estas notas de la versión mediante la acción del conector Azure DevOps Get Query Results.

  5. Asegúrese de que la UAT permita las comprobaciones de validación del negocio y de preparación para la puesta en producción, antes de su aprobación para producción.

Flujo de trabajo de publicación en producción

  1. Promueva los cambios de UAT aprobados en producción mediante canalizaciones en Power Platform.

  2. Generar de nuevo notas de la versión a partir de elementos de trabajo de DevOps por estado, para una comunicación estandarizada de las versiones.

  3. Distribuya las notas de la versión a las partes interesadas técnicas y empresariales a través de canales aprobados, como Teams, Outlook o SharePoint.

Flujo de trabajo de corrección urgente

  1. Solucione problemas urgentes de producción en un entorno dedicado para correcciones urgentes.

  2. Conecte los entornos de corrección urgente a la rama de lanzamiento de Git usada actualmente en producción mediante la integración de Git de Dataverse.

  3. Promueva las revisiones urgentes validadas a producción mediante el mismo mecanismo de canal controlado.

  4. Vuelva a integrar los cambios de corrección urgente desde la rama de lanzamiento en la rama principal para garantizar que se conserven intactos en futuras versiones.

Components

Los siguientes componentes admiten el control de código fuente, la promoción del entorno, la gobernanza y la comunicación de versión en esta arquitectura.

Integración de Git en Power Platform

Función en la arquitectura:Integración de Git de Microsoft Dataverse sincroniza los cambios en las soluciones desde y hacia los entornos de desarrollo con el control de código fuente basado en Git.

Por qué se ha elegido:

  • Habilita ALM con respaldo de origen para los recursos de la solución de Dataverse
  • Admite la colaboración en equipo basada en ramas.
  • Reduce el control manual de exportación e importación

Azure Repos, ramas y elementos de trabajo

Función en la arquitectura:Azure DevOps aloja las ramas main, feature y release, y hace cumplir la gobernanza de las solicitudes de incorporación de cambios (PR). También almacena elementos de trabajo y sirve como fuente estructurada para el ámbito de la versión y los resúmenes de cambios.

Por qué se ha elegido:

  • Incluye sólidos controles de directivas empresariales, como aprobaciones de PR, protección de ramas y registros de auditoría
  • Habilita la alineación nativa con elementos de trabajo y prácticas de gobernanza de versiones
  • Proporciona una definición de ámbito de versión coherente.
  • Admite el filtrado automatizado de elementos listos para lanzamiento
  • Mejora la rastreabilidad entre los cambios de código y el contenido de versión comunicado

Alternativas consideradas: GitHub para repositorios de código y elementos de trabajo del proyecto

Por qué esta arquitectura favorece a Azure DevOps:
Aunque los proyectos de GitHub pueden proporcionar un seguimiento del trabajo flexible, como campos personalizados, vistas de planificación y automatización, esta arquitectura incluye Azure Boards como fuente autorizada de los elementos de trabajo de la versión. Azure Boards proporciona actualmente un modelado de procesos empresariales para elementos de trabajo más sólido, una definición del alcance de versiones basada en consultas compartidas y en el lenguaje de consulta de elementos de trabajo (WIQL), y una trazabilidad integrada más completa del desarrollo y la implementación para operaciones de lanzamiento gobernadas.

Canalizaciones en Power Platform

Rol en la arquitectura:Canalizaciones en Power Platform promueven soluciones entre distintos entornos, incluidas las rutas de promoción de revisiones urgentes.

Por qué se ha elegido:

  • Experiencia de implementación nativa de Power Platform
  • Orquestación de despliegues en función del entorno
  • Accesible tanto para los administradores de plataforma como para los equipos de soluciones

Alternativas consideradas:

Por qué esta arquitectura favorece las canalizaciones en Power Platform:
Esta arquitectura usa canalizaciones en Power Platform como mecanismo de promoción del entorno principal. Reducen la complejidad de la configuración y los requisitos de conocimientos especializados de integración continua e implementación continua (CI/CD) al tiempo que proporcionan una experiencia de implementación nativa y regulada para creadores, administradores y desarrolladores profesionales.

Microsoft Copilot Studio

Función en la arquitectura: Un agente de notas de la versión de Copilot Studio genera notas de la versión estandarizadas a partir de elementos de trabajo aprobados y del contexto de la versión.

Por qué se ha elegido:

  • Reduce el esfuerzo manual de documentación de lanzamiento.
  • Mejora la coherencia y la legibilidad de la comunicación de lanzamientos
  • Admite audiencias duales (empresas y partes interesadas técnicas)

Alternativas consideradas:

  • Creación manual en páginas de correo electrónico o wiki
  • Solo automatización basada en plantillas, sin IA

Por qué esta arquitectura incluye ia:
Demuestra un uso práctico y de bajo riesgo de la IA generativa en un proceso operativo de alto valor, con una supervisión humana clara y rendición de cuentas. Es más flexible cambiar las audiencias, los proyectos y las vías de entrega que la automatización rígida.

Detalles del escenario

La arquitectura es especialmente valiosa para las organizaciones que necesitan admitir varios entornos de desarrollo que funcionan en paralelo (DEV1, DEV2, DEVn) al tiempo que mantienen un origen compartido y regulado de verdad en Git. Cada desarrollador o equipo pequeño puede trabajar en un entorno aislado y sincronizar los cambios a través de flujos de trabajo basados en ramas, lo que permite a los equipos colaborar sin depender de un único entorno de desarrollo compartido.

Valor empresarial

El valor de clave entregado por esta arquitectura incluye:

  • Control de código fuente como origen de verdad para las personalizaciones de soluciones, en lugar de tratar un entorno de creador como origen de implementación autoritativo. Este enfoque mejora la coherencia y facilita la promoción controlada a entornos posteriores.

  • Procedimientos recomendados de seguridad, auditoría y cumplimiento a través del ciclo de vida de desarrollo de software (SDLC), incluidos el control de versiones, las revisiones de código, la rastreabilidad del cambio y la integración con los procesos de gobernanza empresarial.

  • Desarrollo paralelo a escala mediante ramas y entornos de desarrollo aislados para que varios colaboradores puedan compilar e iterar simultáneamente con menos riesgo de colisión.

  • Compatibilidad con entornos de desarrollo de corta duración, lo que permite a los equipos rehidratar entornos de control de código fuente para pruebas, experimentación y escenarios de desarrollo temporales, al tiempo que reduce la expansión del entorno a largo plazo.

  • Productividad del equipo de Fusion, lo que permite a los creadores, desarrolladores y administradores colaborar a través de experiencias nativas de control de código fuente en el producto, a la vez que se alinean con las prácticas empresariales de DevOps.

  • Protección operativa y capacidad de recuperación a través del control de código fuente, que conserva el historial de versiones y admite la restauración a estados anteriores cuando se producen cambios no deseados.

En esta arquitectura, el agente de notas de la versión basado en IA aporta aún más valor al mejorar la comunicación operativa y la transparencia en las versiones. Transforma los elementos de trabajo aprobados de DevOps en notas de versión estandarizadas y amigables con las partes interesadas, lo que reduce el esfuerzo manual al tiempo que conserva la revisión humana y la responsabilidad.

Considerations

Estas consideraciones implementan los pilares de Power Platform Well-Architected, un conjunto de principios rectores que mejoran la calidad de una carga de trabajo. Obtenga más información en Microsoft Power Platform Well-Architected.

Reliability

Esta arquitectura mejora la fiabilidad mediante la implantación de rutas de promoción controladas y una gestión de versiones en función de las ramas. Este enfoque reduce el riesgo de error de implementación y admite la capacidad de recuperación durante escenarios de soporte técnico de producción urgentes.

  • Progresión estandarizada del despliegue desde desarrollo hasta pruebas y producción
  • Ruta dedicada para revisiones urgentes con trazabilidad de la rama de lanzamiento
  • Mecanismos de canalización reutilizables en lugar de implementaciones manuales
  • Comprobaciones de validación antes del paso a producción

Seguridad

Esta arquitectura aplica la seguridad a través de privilegios mínimos, separación de roles e identidades de automatización controladas. Este enfoque reduce el riesgo de cambios no autorizados y mejora la responsabilidad de los cambios.

  • Control de acceso basado en rol en entornos de Power Platform y Azure DevOps
  • Entidades de servicio o identidades administradas para la ejecución de la canalización
  • Permisos de implementación de producción restringidos
  • Actividades auditables de fusión de ramas y publicación
  • Canales aprobados para la distribución de notas de versión

Excelencia operativa

Esta arquitectura tiene una puntuación alta para la excelencia operativa. Un modelo de administración de versiones repetible y escalable mejora la excelencia operativa y admite la entrega regulada en varios equipos y entornos.

  • Estrategia de rama codificada (característica, principal, versión)
  • Proceso de promoción de entorno repetible
  • Patrón estandarizado de gestión de correcciones urgentes
  • Generación automatizada de notas de lanzamiento integrada en el flujo de trabajo de lanzamiento
  • Reducción de la dependencia de los conocimientos tribales para la comunicación de lanzamiento

Eficiencia en el rendimiento

Esta arquitectura optimiza la eficacia del proceso de entrega más que el rendimiento de la aplicación en tiempo de ejecución, que es adecuado para una arquitectura de referencia de ALM. Al admitir flujos de desarrollo paralelos y reducir la coordinación manual entre las actividades de versión, aumenta el rendimiento de la entrega de cambios al reducir el esfuerzo operativo por versión.

  • Comunicación automatizada de despliegues y lanzamientos
  • Reducción de la sobrecarga de coordinación manual
  • Flujo de trabajo estandarizado para ciclos de versión más rápidos
  • Escalar a flujos paralelos de DEVn sin rediseñar la gobernanza

Optimización de la experiencia

Esta arquitectura admite un proceso de versión predecible y bien definido en entornos de desarrollo, pruebas y producción, lo que mejora la colaboración entre creadores, desarrolladores, administradores de versiones y equipos de soporte técnico.

  • Flujos de trabajo alineados con roles
  • Modelo de promoción predecible
  • Formato y plazos coherentes para las notas de versión
  • Se minimizó la ambigüedad en los traspasos entre equipos

La experiencia se ha mejorado para varios grupos de usuarios:

  • Desarrolladores y creadores mediante flujos de trabajo claros, para entornos y ramas
  • Administradores de versiones a través de la promoción estandarizada y la rastreabilidad
  • Partes interesadas de negocio mediante resúmenes de lanzamiento asistidos por IA fáciles de leer
  • Equipos de soporte técnico mediante un proceso definido de revisión

Inteligencia artificial responsable

  • Equidad: la funcionalidad de IA resume los elementos de trabajo de versión aprobados. No toma decisiones del personal, determina la idoneidad ni toma decisiones que afectan a los clientes.

  • Confiabilidad y seguridad: los revisores humanos comprueban el contenido antes de la distribución.

  • Privacidad y seguridad: El agente procesa solo los metadatos de lanzamiento empresariales incluidos en el alcance, como los elementos de trabajo aprobados y el contexto del lanzamiento. Siga las políticas de gobernanza de datos y de conectores de su organización para la gestión de datos sensibles.

  • Inclusión: la salida generada admite audiencias técnicas y no técnicas con secciones estructuradas y resúmenes de lenguaje simple.

  • Transparencia: etiquete las notas de la versión como asistida por IA y vincule la fuente de verdad revisada a los elementos de trabajo de origen reales en DevOps.

  • Responsabilidad: un responsable de lanzamiento designado o un aprobador del despliegue sigue siendo responsable del contenido final de la versión y de las decisiones sobre el despliegue en producción.

Pasos siguientes

  1. Conecte los entornos de desarrollo de Dataverse a un repositorio de Git.
  2. Planee su Azure DevOps estructura y estrategia de la organización.
  3. Extraer elementos de trabajo desde DevOps con Copilot Studio mediante el uso de conectores como herramientas.

Colaboradores

Microsoft mantiene este artículo. Los siguientes colaboradores escribieron este artículo.

Autores principales:

  • Last updated on