Definir la administración del ciclo de vida de las aplicaciones
La mayoría de los proyectos tendrán un plan y un equipo de control de calidad total. Sin embargo, cada miembro del equipo de creadores debe participar de alguna manera para garantizar soluciones de calidad. Desde las pruebas unitarias, como la configuración para ayudar en las canalizaciones de versiones con Azure DevOps, hay muchos puntos en un proyecto que pueden influir y guiar hacia el éxito.
Administración del ciclo de vida de las aplicaciones (ALM)
En términos generales, el arquitecto de soluciones o un ingeniero de DevOps será el propietario del proceso de ALM. Pero como miembro clave del equipo de creadores, es necesaria su participación bajo su dirección. Para tener éxito, deberá comprender y seguir los procesos de ALM, según lo definido por el arquitecto de soluciones (o ingeniero de DevOps). Haga preguntas, ofrezca documentar el plan y obtenga la confirmación de que lo ha comprendido. Mientras crea esta documentación, también aprenderá más sobre los planes de ALM para el proyecto.
A medida que vaya creando, validará su trabajo mediante el uso de herramientas de la plataforma como el comprobador de aplicaciones, el comprobador de flujo y el comprobador de soluciones.
Todo su trabajo se llevará a cabo en el contexto de una solución y debe comprender cómo crear, exportar e importar soluciones según las instrucciones del arquitecto de soluciones. Para un proyecto más grande, es probable que encuentre canalizaciones de compilación más formalizadas y una implementación continua automatizada.
Empaquetador de soluciones
El empaquetador de soluciones debe usarse para tomar la solución no administrada en desarrollo y prepararla para almacenarla en un repositorio del control de código fuente. El empaquetador de soluciones toma el archivo de solución único y lo divide en archivos individuales que representan cada componente de la solución. Este proceso de empaquetador de soluciones se conoce como desempaquetar la solución. Luego, la salida del empaquetador de soluciones se inserta en el repositorio de control de código fuente. Esta versión de salida que se inserta ahora representa la fuente fiable del proyecto.
El empaquetador de soluciones también puede empaquetar la carpeta desde el control de código fuente, recreando el archivo de solución único. Los archivos que se insertan en el repositorio de control de código fuente se utilizan para crear las soluciones que se importarán a los otros entornos. Aunque el empaquetador de soluciones se puede ejecutar manualmente, lo más habitual es que se ejecute mediante Microsoft Power Platform Build Tools como parte de una canalización automatizada.
Implementador de paquetes
La herramienta le permite crear un paquete que incluye múltiples soluciones, datos de la herramienta de migración de configuración y la lógica del código del desarrollador que se ejecuta antes y después de que se complete la importación del paquete. En muchos sentidos, podría pensar en Package Deployer como un asistente de instalación para Microsoft Power Platform. El implementador de paquetes se puede ejecutar de forma interactiva para importar manualmente paquetes y datos en un entorno. El implementador de soluciones también admite la ejecución a través de PowerShell, lo que permitiría la automatización y la integración en Azure Pipelines.
Comprobador de soluciones
Como Power Automate y Power Apps se utilizan para personalizar una implementación, cada uno ofrece sus propios comprobadores de aplicaciones en línea, que son útiles para la resolución de problemas en tiempo real. Sin embargo, el comprobador de soluciones (más detalles aquí) puede ver la solución completa, realizar un análisis estático y producir una lista detallada de los problemas encontrados.
El comprobador de soluciones debe ejecutarse regularmente en cualquier solución no administrada que esté creando en sus entornos de desarrollo. El comprobador de soluciones puede analizar los flujos de Power Apps y Power Automate, así como activos de código, como complementos que crean los desarrolladores. El equipo del proyecto puede ejecutar manualmente el verificador de soluciones desde el portal del creador seleccionando la solución y luego ejecutando el comprobador. El comprobador de soluciones también se puede automatizar para que se ejecute como parte de un proceso de compilación mediante tareas de canalización de PowerShell o Azure Pipeline. Al automatizar la ejecución del comprobador de soluciones, puede convertirse en una parte integral del proceso de compilación e incluso se puede configurar para detener la compilación si se han producido demasiados errores. El simple hecho de ejecutar el comprobador de soluciones no es suficiente para que el equipo tenga éxito; también debe haber un plan para evaluar y resolver regularmente los problemas identificados.
Automatizar implementación
Un área que es tan importante como parte del plan de creación es analizar qué automatización se puede usar para hacer que el proceso sea repetible. Microsoft y la comunidad proporcionan numerosas herramientas que se pueden usar para automatizar el proceso de creación. Microsoft está invirtiendo en Azure DevOps y un conjunto de tareas de Microsoft Power Platform que se pueden utilizar para automatizar las tareas de implementación y administración de la solución. Por ejemplo, un equipo podría tener un Azure Pipeline de que todos los días a las 19:00 extrae elementos del desarrollo y los registra en un repositorio de git. La misma canalización también se puede utilizar para ejecutar el comprobador de soluciones, de modo que cuando el equipo entre por la mañana, sepa de inmediato si hubo algún problema identificado en la compilación de la noche anterior. La canalización también podría importar la solución a un entorno de creación limpio que permitirá la detección de cualquier dependencia que se haya introducido involuntariamente durante el desarrollo de ese día. Esto asegura que lo que se registra en el control de código fuente es una versión limpia lista para su implementación en otros entornos. Las canalizaciones también se pueden utilizar para automatizar las pruebas, de modo que sea solo un paso más dentro de la canalización. Azure Pipelines también se usa para producir el artefacto de solución administrada que se usará en las canalizaciones de lanzamiento para implementar en los entornos ascendentes, como los de pruebas y producción. El mismo artefacto de solución que se utilizó en la prueba se utiliza hasta la producción. Esto asegura que no se introducen nuevos cambios sorprendentes a medida que avanza la promoción a través de la serie de entornos que terminan en el de producción. Azure Pipelines también se puede usar para crear activos de código de desarrollador a fin de garantizar que no se generen en una estación de trabajo de desarrollador local.
Control de versiones
De forma predeterminada, a medida que los cambios avanzan de desarrollo a prueba y a producción, representa una única secuencia de trabajo de cambios. Si se identifica un problema en producción, lo solucionaría en desarrollo y luego lo promovería a través de la serie de entornos de regreso a producción. Un solo flujo de trabajo como este funciona bien si no se realiza ningún desarrollo nuevo. Si el equipo de desarrollo ya pasó a la versión 2 en su entorno de desarrollo y luego corrige un error que se identificó en producción, a medida que la corrección se traslada a producción, también lo haría el trabajo en curso para la versión 2, porque se mezcló todo. La acción ideal es cuando el cambio se realiza en un entorno de desarrollo de secuencia de trabajo independiente que representa solo lo que ya estaba en producción y lo que se promocionó solo incluía la corrección, nada de la versión 2. Esto requiere que el equipo del proyecto planifique con anticipación y tenga una estrategia para administrar múltiples versiones activas. Podría ser tan simple como una secuencia de desarrollo activa y una secuencia de mantenimiento para respaldar la producción. Los proyectos más complejos pueden incluso tener múltiples secuencias de desarrollo activas al mismo tiempo.
Gestionar las secuencias de desarrollo y mantenimiento activas al mismo tiempo generalmente tiene lugar a través de una combinación de entornos de Dataverse y ramas de control de código fuente. Las ramas permiten tener una copia de los activos del proyecto y una forma aislada de realizar cambios en un entorno asociado a esa rama. Los cambios de una rama se pueden fusionar mediante combinación con otra rama. La estrategia de ramificación debe mantenerse lo más simple posible para evitar tener que resolver muchos conflictos durante la fusión de ramificaciones.