Estrategias de implementación modular
Asignar un ruleset a un solo tipo de caso ayuda a promover la reutilización. Entre los motivos para asignar un ruleset a un solo tipo de caso, se incluyen los siguientes:
- Lograr un desarrollo basado en ramas de integración continua (CI).
- Fomentar las historias de usuario orientadas a los casos usando la metodología Scrum de Agile Studio para gestionar los lanzamientos de software del proyecto.
- Gestionar ramas que contienen reglas que se originan en diferentes rulesets. Cuando esto ocurre, se genera un ruleset de rama, y el ruleset generado antepone el nombre del ruleset original al nombre de la rama.
- Adaptar varias historias de usuario en una rama.
- Simplificar la capacidad de completar el campo Work item to associate (Objeto de trabajo para asociar) de Agile Workbench cuando se verifica una regla en una rama.
Cuando crea un proyecto en Agile Studio, también se crea un objeto de trabajo del backlog. Cuando se desarrolla una aplicación basada en una aplicación de referencia, el backlog de Agile Studio puede completarse automáticamente con una historia de usuario para cada tipo de caso de aplicación de referencia. Los tipos de casos apropiados para el lanzamiento del minimum lovable product (MLP) pueden seleccionarse de dicho backlog.
El Deployment Manager de Pega (Gerente de implementación) proporciona una forma de gestionar los conductos de integración y entrega continuas (CI/CD), incluida la compatibilidad con el desarrollo basado en ramas. Es posible disparar automáticamente una implementación de desarrollo (Dev) a control de calidad (QA) cuando una sola rama se fusiona correctamente con la aplicación principal. Las reglas verificadas en dicha rama solo deben pertenecer a la aplicación principal para que esto ocurra.
Cuando se crea una clase de tipo de caso dentro de un ruleset específico de tipo de caso, las reglas generadas por el Case Designer (Diseñador de casos) en Dev Studio se agregan a dicho ruleset a pesar de que el diseñador de casos es compatible con el desarrollo de varios tipos de casos dentro de la misma aplicación.
Revisión del desarrollo basado en ramas
Las ramas de la aplicación se gestionan en App Explorer de Dev Studio.
Aunque no es necesario asignar una rama a un solo tipo de caso, como se muestra en la siguiente imagen, hacerlo simplifica el proceso de revisión de ramas.
Cuando se guarda una regla relacionada con un caso en un ruleset específico del caso en una rama, se genera un ruleset de rama específico del caso si aún no existe uno. Los cambios realizados en el diseñador de casos que afectan a dicha regla se producen en la versión del ruleset de rama de dicha regla. Cuando se crea un ruleset de rama, se coloca en la parte superior del ruleset stack de la aplicación.
La fusión de una sola rama se inicia desde la pestaña Branches (Ramas) de Application Explorer haciendo clic con el botón secundario en el nombre de la rama para que aparezca un menú.
Al final del proceso de fusión, la rama estará vacía si no se selecciona la opción Keep all source rules and rulesets after merge (Conservar todas las reglas y rulesets de origen después de la fusión). La rama puede usarse entonces para los siguientes conjuntos de tareas, problemas o bugs definidos en Agile Studio.
Desarrollo basado en ramas del gerente de implementación
Considere un escenario en el que la aplicación Deployment Manager (Gerente de implementación), que se ejecuta en un servidor de orquestación separado, está configurada para iniciar automáticamente una entrega cuando una fusión de una sola rama completa una aplicación correctamente. Además, supongamos que la aplicación del entorno de desarrollo, creada en la misma aplicación PegaDevOpsFoundation, ajusta la configuración dinámica del sistema (D-S-S) del RMURL (Release Manager URL) para que señale a PRRestService del servidor de orquestación. Al iniciar una fusión de una sola rama, el entorno de desarrollo le envía una solicitud a la aplicación Deployment Manager (Gerente de implementación). La aplicación organiza el empaquetado de la aplicación dentro del entorno de desarrollo, la publicación de ese paquete en un repositorio mutuo de desarrollo (Dev) y control de calidad (QA), y la importación de dicho paquete en el entorno de control de calidad (QA).
Empaquetado de aplicaciones
La pantalla inicial del asistente de empaquetado de aplicaciones pregunta qué aplicaciones incorporadas y la aplicación que se está empaquetando deben incluirse en la regla de producto generada. Tenga en cuenta que también se mencionan los componentes; un componente es Rule-Application, donde pyMode = Component.
No se recomienda que varias aplicaciones hagan referencia al mismo ruleset. Después de guardar una regla de aplicación con un nuevo nombre, aparecen advertencias en ambas aplicaciones: una advertencia por cada ruleset con doble referencia.
La estrategia de implementación es diferente cuando la aplicación de producción que se implementa depende de otras diversas aplicaciones de componente incorporado.
Si el archivo de producto contiene cambios de esquema de base de datos como parte de la implementación, y si las políticas de su organización no son compatibles con la aplicación automática de los cambios de esquema de base de datos, deberá generar el SQL para los cambios de esquema y hacer que el administrador de bases de datos (DBA) lo ejecute manualmente antes de continuar con la implementación de las reglas.
Considere el ejemplo de la aplicación de reservas de FSG. La aplicación FSGEmail se empaqueta en primer lugar, seguida de la aplicación de hotel, seguida de la aplicación de reservas.
Aunque es posible definir una regla de producto que empaquete solo un componente, no es necesario hacerlo. El componente se puede empaquetar usando la propia regla del componente, como se muestra en la siguiente imagen.
El Deployment Manager (Gerente de implementación) es compatible con los conductos de las instancias de reglas en las que pyMode = Application y pyMode = Component. Cuando se empaqueta una aplicación que contiene uno o más componentes, estos también deben empaquetarse.
El principio de abierto/cerrado aplicado al empaquetado y la implementación
La meta del principio de abierto/cerrado es eliminar los efectos dominó. El efecto dominó se produce cuando un objeto realiza cambios en su interfaz, en lugar de definir una nueva interfaz y dejar de usar la existente. La interfaz principal de las aplicaciones sobre las que se crean otras aplicaciones, como FSGEmail y Hotel, son los datos necesarios para construir la nueva interfaz mediante la propagación de datos. Si el componente EmailEditor exige una nueva propiedad, la aplicación FSGEmail debe cambiar su interfaz para las aplicaciones que se desarrollan por encima de este, como la aplicación de hotel. La aplicación de hotel tiene que cambiar su interfaz incorporada para permitir que la aplicación de reservas proporcione el valor de la nueva propiedad obligatoria.
Al implementar las aplicaciones por separado y en orden creciente de dependencia, el cambio del componente EmailEditor finalmente está disponible para la aplicación de reservas sin interrumpir esa aplicación o las aplicaciones que están por debajo de ella.
Nota: No se recomienda actualizar las tres aplicaciones (FSGEmail, Hotel y Reservas) usando una rama asociada con la aplicación de reservas.
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
¿Quiere ayudarnos a mejorar este contenido?