Prácticas recomendadas para el desarrollo basado en el equipo

Los desarrolladores de Pega Platform™ usan prácticas rápidas para crear aplicaciones en un entorno de desarrollo compartido que aprovecha las ramas para confirmar los cambios.

Siga estas prácticas recomendadas para optimizar el proceso de desarrollo:

• Aprovechar varias aplicaciones incorporadas para desarrollar aplicaciones de componente más pequeñas. Las aplicaciones más pequeñas son más fáciles de desarrollar, probar y mantener.
• Usar ramas cuando varios equipos contribuyen a una sola aplicación. Usar el explorador de ramas para ver la calidad, los puntajes del sistema de contención y las pruebas unitarias de las ramas.
• Asegurarse de que expertos revisen las ramas antes de fusionarlas. Crear revisiones y asignar revisiones por parte de expertos desde el explorador de ramas y usar Pulse para colaborar con sus compañeros de equipo.
• Usar las herramientas para desarrolladores de Pega Platform, como la utilidad de comparación de reglas, para determinar cómo abordar los conflictos de reglas.
• Ocultar el trabajo incompleto o riesgoso usando alternancias para facilitar la fusión continua de las ramas.
• Crear casos de prueba de PegaUnit para validar los datos de la aplicación comparando los valores de propiedad esperados con los valores reales devueltos al ejecutar la regla.

El siguiente diagrama muestra cómo varios equipos de desarrollo interactúan con el sistema de registro (SOR).

 " data-embed-button="image_browser" data-entity-embed-display="view_mode:media.embedded" data-entity-embed-display-settings="" data-entity-type="media" data-entity-uuid="f1825aac-d5f2-4744-94f8-56f55b79830d">

1. El proceso comienza cuando el Equipo A solicita una revisión de ramas con el sistema de registro.
2. Un revisor de ramas primero solicita la detección de conflictos y luego ejecuta las pruebas de PegaUnit correspondientes. Si el revisor de ramas detecta conflictos, o si alguna de las pruebas de PegaUnit falla, el revisor notifica al desarrollador que solicita la rama. El desarrollador detiene el proceso para corregir los problemas.
3/4. Si la revisión no detecta conflictos, y las pruebas de PegaUnit se ejecutan correctamente, la rama se fusiona con el sistema de registro.
5. Las versiones del ruleset asociadas con la rama se bloquean a continuación.
6. El Equipo B remoto ahora puede realizar un reajuste bajo demanda de las reglas de la aplicación SOR en su sistema. Un reajuste extrae los commits más recientes realizados a la aplicación SOR en el sistema de desarrolladores del Equipo B.

Para obtener más información, consulte Flujo de trabajo de desarrollo en el conducto de DevOps.

El siguiente diagrama de secuencia describe el proceso usando como ejemplo los cambios en la aplicación de correo electrónico de FSG:

 " data-embed-button="image_browser" data-entity-embed-display="view_mode:media.embedded" data-entity-embed-display-settings="" data-entity-type="media" data-entity-uuid="996997f7-2bc6-4883-928b-dfc7534d5e66">

Actores:

• Desarrollador: miembro del equipo de desarrollo de la empresa responsable de implementar una nueva función en la aplicación FSGEmail.
• Revisor de ramas: miembro del equipo de desarrollo de la empresa responsable de la revisión del código de las solicitudes del desarrollador y de la fusión si la revisión del código es correcta.
• Pega SOR: instancia de Pega configurada como SOR. Esta instancia se encarga de los últimos cambios estables realizados en la aplicación FSGEmail.
• Equipo de la aplicación de reservas: equipo de desarrollo responsable de las aplicaciones de reservas y de hotel.

Proceso:

• El equipo de desarrollo de la empresa implementa los cambios relacionados con una nueva función de la aplicación FSGEmail.
• Un desarrollador del equipo de la empresa solicita una revisión de ramas con el sistema de registro.
• Un revisor de ramas primero solicita la detección de conflictos y luego ejecuta las pruebas de PegaUnit correspondientes.
• Si el revisor de ramas detecta conflictos, o si alguna de las pruebas de PegaUnit falla, el revisor notifica al desarrollador que solicita la revisión de ramas. El revisor de ramas detiene el proceso para permitirle al desarrollador corregir los problemas.
• Si la revisión no detecta conflictos, y las pruebas de PegaUnit se ejecutan correctamente, la rama se fusiona con el sistema de registro. Las versiones del ruleset asociadas con la rama se bloquean a continuación.
• El equipo de la aplicación de reservas ahora puede realizar un reajuste bajo demanda de las reglas de la aplicación SOR en su sistema.
• Un reajuste extrae los commits más recientes realizados a la aplicación SOR en el sistema del equipo de la aplicación de reservas.

Cuando se desarrolla inicialmente una aplicación, las versiones abiertas del ruleset son necesarias y deseables. En algún momento, se puede hacer una transición para que los rulesets sin ramas de la aplicación permanezcan siempre bloqueados.

Cuando se fusiona una rama, existe la opción de elegir Create new version (Crear nueva versión) y Lock target after merge (Bloquear destino después de la fusión) para facilitar las operaciones de reajuste. Un sistema que solicita un reajuste desde el host SOR siempre bloqueado de un ruleset detecta las versiones recién creadas y bloqueadas del ruleset antes de continuar con el reajuste o la cancelación.