Consideraciones clave para ALM

8 minutos

Los arquitectos de soluciones deben definir la estrategia para la administración del ciclo de vida de las aplicaciones (ALM) del proyecto. Esta tarea forma parte del proceso de ayudar a la organización a establecer la gobernanza adecuada para la solución.

Estrategia del entorno

Un entorno es un contenedor que almacena, administrar y comparte datos empresariales, aplicaciones, flujos, conexiones y otros activos; junto con permisos para permitir que los miembros de la organización usen los recursos.

Un entorno sirve como contenedor para diferenciar aplicaciones distintas que pueden tener roles, requisitos de seguridad o públicos objetivo diferentes. La forma en que decida utilizar los entornos dependerá de la organización y de las aplicaciones que esté intentando crear, por ejemplo:

Puede decidir crear las aplicaciones en un único entorno.
Puede crear entornos distintos que agrupen las versiones de prueba y de producción de sus aplicaciones.
Puede crear entornos distintos que correspondan a equipos o departamentos específicos de su empresa, cada uno con los datos y las aplicaciones relevantes para cada público.
Puede crear entornos distintos para diferentes ramas del mundo de su empresa.

El desarrollo una estrategia de entorno implica configurar entornos y otras capas de seguridad de datos de manera que respalde el desarrollo productivo de su organización y, al mismo tiempo, proteja y organice los recursos. Una estrategia para administrar el aprovisionamiento y el acceso al entorno, y para controlar los recursos dentro de este, es importante para:

Proteger los datos y el acceso.
Saber cómo usar correctamente el entorno predeterminado.
Administrar la cantidad correcta de entornos para evitar la proliferación y conservar la capacidad.
Facilitar la administración del ciclo de vida de las aplicaciones (ALM).
Organizar los recursos en particiones lógicas.
Apoyar las operaciones (y el servicio de asistencia técnica) en la identificación de aplicaciones que están en producción al tenerlas en entornos dedicados.
Asegurarse de que los datos se almacenan y transmiten en regiones geográficas aceptables (por motivos de rendimiento y cumplimiento).
Garantizar el aislamiento de las aplicaciones que se están desarrollando.

Los siguientes tipos de entornos están disponibles en Microsoft Power Platform:

Espacio aislado: un entorno de espacio aislado es cualquier entorno de Dataverse que no sea de producción. En aislamiento de la producción, un espacio aislado es el lugar en el que desarrollar y probar de forma segura los cambios en las aplicaciones con poco riesgo.
Producción: el entorno donde las aplicaciones y otro software se ponen en funcionamiento para su uso previsto.
Comunidad (desarrollador): el Plan de la comunidad de Power Apps le brinda acceso a un usuario a una funcionalidad premium de Power Apps, Dataverse y Microsoft Power Automate solo para uso individual. Este entorno está destinado principalmente para propósitos de aprendizaje. Un entorno de desarrollador es un entorno de un solo usuario y no se puede usar para ejecutar o compartir aplicaciones. Un entorno del Plan de la comunidad puede participar en la canalización de Azure DevOps.
Predeterminado: se crea automáticamente un único entorno predeterminado para cada inquilino y todos los usuarios de ese inquilino lo comparten. Los servicios de Microsoft 365 usan el entorno predeterminado.
Prueba: los entornos de prueba son para probar nuevas características o para realizar pruebas de concepto. Los entornos de prueba se eliminan automáticamente después de 30 días.

Importante

El arquitecto de soluciones debe definir cuántos entornos se requieren, sus propósitos y las dependencias entre los entornos. Como mínimo, una práctica de ALM correcta debe incluir el uso de un entorno de prueba antes de implementar cualquier cosa en el entorno de producción. Esta práctica garantiza que disponga de un lugar para probar su aplicación, pero también garantiza que pueda probar la implementación.

Para obtener más información, consulte entornos y estrategia del entorno.

Gestionar soluciones y otros códigos y componentes que no son compatibles con la solución

Los proyectos de Microsoft Power Platform constan de componentes que se pueden empaquetar en soluciones en entornos y componentes que no se pueden agregar a soluciones. Los componentes no agregables incluyen componentes implementados en Azure, datos de configuración e informes de Power BI. El plan de ALM debe considerar la forma de gestionar estos componentes no compatibles con la solución.

El arquitecto de soluciones debe decidir si la administración del ciclo de vida de las aplicaciones se administrará mediante el uso de soluciones o mediante el control del código fuente. Tradicionalmente, los proyectos de Microsoft Power Platform se han centrado más en el entorno, pero ahora muchos están avanzando hacia un enfoque centrado en el control de código fuente.

Si usa un enfoque centrado en el entorno, entonces:

El entorno de desarrollo es la copia maestra de todos los cambios.
Los cambios se promueven directamente desde desarrollo > prueba> producción.

Si usa un enfoque centrado en el control de código fuente, entonces:

El control de código fuente es el maestro.
El entorno de desarrollo se vuelve a crear a partir del control de código fuente (este proceso se puede automatizar y repetir).
Los cambios del entorno de desarrollo se registran en el control de código fuente.

Un enfoque centrado en el control de código fuente le anima a tener un maestro definitivo y la capacidad de volver a crear entornos de desarrollo para cualquier versión con seguimiento. Actualmente, Microsoft está fomentando y creando herramientas para admitir ALM centrado en el control de código fuente.

Nota

Lo ideal es que todos los entornos que no sean de producción se desechen, en otras palabras, los entornos de desarrollo y prueba se pueden eliminar y volver a crear sin sufrir pérdidas.

El uso de un enfoque centrado en el control de código fuente permite un enfoque de Azure DevOps con canalizaciones de compilación y lanzamiento. El uso de un enfoque centrado en el entorno significa que debe definir el flujo de trabajo para los creadores y desarrolladores de aplicaciones. El arquitecto de soluciones debe definir cómo y quién promueve la aplicación a través de los entornos desde el desarrollo hasta la producción.

El arquitecto de soluciones también tendrá que definir cómo configurar cada entorno y buscar formas de hacerlo más sencillo.

Trabajo en equipo

En comparación con el desarrollo de aplicaciones tradicionales, los proyectos de Microsoft Power Apps se diferencian en dos aspectos fundamentales:

Cómo colaboran los distintos miembros del equipo del proyecto para crear la solución
Metodología de desarrollo

Power Apps es una plataforma que beneficia a desarrolladores profesionales y a desarrolladores civiles. En un entorno de desarrollo tradicional, solo los desarrolladores profesionales pueden participar en la creación real de una aplicación. Con Power Apps, todo el mundo tiene la capacidad de crear las aplicaciones que necesitan mediante el uso de funcionalidad avanzada que antes solo estaban disponibles para desarrolladores profesionales. Power Apps democratiza la experiencia de creación de aplicaciones empresariales personalizadas ya que permite a los usuarios crear aplicaciones empresariales personalizadas con múltiples características sin escribir código.

Diagrama que muestra el ecosistema en desarrollo.

Con Power Apps, puede crear rápidamente una versión utilizable de su aplicación porque Power Apps brinda una experiencia de desarrollo WYSIWYG (lo que se ve es lo que se obtiene). Puede experimentar la aplicación de trabajo real al principio del proceso de desarrollo y, si surgen nuevos requisitos, puede agregar nuevas características a la próxima versión.

Entre los problemas con la personalización y el desarrollo de componentes dentro de Microsoft Power Platform se incluyen:

Microsoft Power Platform no admite el control de versiones de componentes (excepto para aplicaciones de lienzo).
Los usuarios no pueden trabajar en el mismo componente de Microsoft Power Platform de manera simultánea.
Las aplicaciones basadas en modelo tienen varios componentes, cada uno con sus propios editores, lo que permite dividir el trabajo entre los creadores. Por el contrario, las aplicaciones de lienzo solo tienen un editor y solo una persona puede trabajar en una aplicación a la vez. Al usar componentes de lienzo, puede permitir que varios creadores trabajen en la misma aplicación de manera simultánea.

Los arquitectos de soluciones deben establecer el flujo de trabajo para que los creadores de aplicaciones realicen cambios y los promuevan. La comunicación proactiva y las asignaciones de trabajo deben administrarse para minimizar los conflictos entre los creadores.

Puede minimizar los conflictos entre creadores mediante la creación de un entorno individual para cada creadores. Los entornos de creadores individuales ofrecen aislamiento y seguimiento, pero requieren un esfuerzo adicional para combinar el trabajo y resolver conflictos. Un entorno de creador compartido puede ser menos complejo, pero no ofrece aislamiento entre los creadores de aplicaciones y carece de detalles en el seguimiento de los cambios.

Control de código fuente

Aunque esté usando un enfoque centrado en el entorno, debe decidir dónde residirán la copia maestra de las soluciones y el código.

Los activos de código de desarrollador compatibles con la solución (como complementos, componentes de código PCF y scripts de formulario (transpilados desde TypeScript)) deben "basarse" en un entorno de compilación y no en el escritorio del desarrollador. Después de crearse, los activos deben implementarse en un entorno desde el que se exportará la solución maestra o se integrarán en una solución que se instalará.

Herramientas

Microsoft proporciona varias herramientas y aplicaciones que puede usar con ALM en Microsoft Power Platform:

Centro de administración de Microsoft Power Platform: proporciona un portal unificado para que los administradores creen y administren entornos.
Power Apps build tools: automatizan tareas comunes de compilación e implementación relacionadas con Power Apps mediante Azure DevOps.
GitHub: sistema popular de control de versiones.
Configuration Migration tool: permite mover datos de configuración o referencia entre entornos.
Package Deployer: le permite implementar paquetes de activos para instancias de Dataverse. Los paquetes pueden constar de archivos de solución y archivos planos, código personalizado, archivos HTML y datos.
Empaquetador de soluciones: una herramienta que puede desempaquetar un archivo de solución comprimido en varios archivos XML y otros archivos para que se puedan administrar con facilidad con un sistema de control de código fuente.
Microsoft Power Apps CLI: una sencilla interfaz de línea de comandos que permite a los desarrolladores crear componentes de código.
Módulo PowerShell de implementación de paquetes: se usa para implementar paquetes en el entorno de Dataverse.
Módulo PowerShell de comprobador de Power Apps: interactúa con el servicio del comprobador de Power Apps para que pueda ejecutar trabajos de análisis estático y descargar los resultados.