Patrones erróneos comunes en el desarrollo en equipo
Con Power Platform, los equipos pueden aplicar patrones comunes de Integración e implementación continua (CI/CD) con soluciones administradas y no administradas. En este módulo, veremos un antipatrón común que se usa a menudo al comienzo del desarrollo con Power Platform; después, veremos un método con el que obtendremos mejores resultados a largo plazo.
Antipatrón común: uso excesivo de soluciones no administradas
El patrón más común (y problemático) en el desarrollo con Power Platform es el uso excesivo de soluciones no administradas, tanto para el desarrollo como para la implementación.
Como se muestra en el siguiente diagrama, este método genera un entorno de producción incorrecto a largo plazo, a medida que se van acumulando soluciones no administradas:
Por qué usan los equipos soluciones no administradas
En las primeras etapas del desarrollo, los equipos suelen optar por implementar soluciones no administradas porque creen que eso simplificará el proceso de implementación y acelerará la entrega.
Ejemplo:
Un equipo de desarrollo que esté creando un sistema de emisión de tickets podría crear una solución no administrada llamada TicketingUpdates_Sprint1 e implementarla directamente en producción. Para el siguiente sprint, podrían crear otra solución no administrada llamada TicketingUpdates_Sprint2 y hacer lo mismo. Este patrón continúa en todos los sprints.
¿Por qué es esto un problema?
Con el tiempo, este método tendrá el siguiente resultado:
- Varias soluciones no administradas en producción.
- Un entorno desordenado que se vuelve difícil de mantener.
- Pérdida de visibilidad sobre qué cambios se han hecho, cuándo y por quién.
Estos equipos también se pierden algunas ventajas, como las siguientes:
- El uso del control de código fuente para hacer un seguimiento de los cambios.
- La aplicación de capas de soluciones para administrar mejor las personalizaciones.
- El uso de soluciones administradas para que las implementaciones sean más seguras y estén más controladas.
Los peligros
Estos son algunos de los riesgos principales al usar soluciones no administradas en todas las implementaciones:
No hay control de código fuente
Por ejemplo, si el desarrollador A elimina una tabla y el desarrollador B le cambia el nombre en una solución no administrada diferente, no hay forma automatizada de detectar y resolver ese conflicto.Ahorro mínimo de tiempo
La mejora percibida en la velocidad de implementación suele ser pequeña y no supera los problemas de mantenimiento a largo plazo.
Un patrón superior para el desarrollo en equipo
Un método más sostenible consiste en utilizar uno o más entornos de desarrollo dedicados. Esto permite que varios desarrolladores colaboren de manera eficiente sin crear una expansión descontrolada de soluciones no administradas.
Los desarrolladores hacen cambios en sus respectivos entornos.
Los cambios en esos entornos se exportan y, después, se registran en el control de código fuente.
El registro de una solución en el control de código fuente puede desencadenar uno de varios eventos, como un proceso de compilación para mover la solución a entornos de fase descendente.
Este modelo promueve lo siguiente:
- Entornos más limpios.
- Colaboración más sencilla.
- Menos conflictos durante el desarrollo.
- Cambios más rastreables.
Un método moderno para el desarrollo de soluciones
En el siguiente vídeo, podrá ver una demostración de la integración continua en el desarrollo moderno en Power Platform:
Una ayuda para el desarrollo en equipo
Todo proyecto de software comienza por tener un plan, y la configuración de la administración del ciclo de vida de las aplicaciones (ALM) para Power Platform no es una excepción.
Aunque en este módulo no nos centraremos en la planificación, es importante entender que, para planificar y administrar eficazmente los elementos de trabajo, es imprescindible evitar los problemas más comunes del desarrollo en equipo.
Recomendaciones principales:
Los elementos de trabajo deben ser pequeños, específicos y tener una duración limitada.
Ejemplo: en lugar de asignar un elemento "Crear todo el sistema de administración de casos", cree tareas más pequeñas, como "Añadir campo de prioridad a la tabla Case" o "Crear flujo para las actualizaciones del estado de los casos".Evite la superposición de trabajos en los mismos componentes.
Ejemplo: si dos desarrolladores intentan personalizar el mismo formulario de contacto al mismo tiempo, es posible que los cambios se sobrescriban.Valore la posibilidad de asignar a alguien para que se encargue de mantener los procesos ALM.
Aunque es necesario tener un recurso de ALM dedicado, los equipos que lo tienen suelen ver mejores resultados a largo plazo, especialmente a medida que los proyectos crecen en escala.
