Responsabilidades en la implementación del LSA

La primera responsabilidad del Lead System Architect (LSA) es evaluar la seguridad de la aplicación. El LSA puede realizar esta evaluación verificando la lista de verificación de seguridad. Si no se completa la lista de verificación de seguridad de la aplicación, se bloquea la implementación de esta. Esta tarea:

• Realiza una evaluación detallada de su configuración de seguridad actual para determinar si los ajustes siguen las prácticas recomendadas para el desarrollo de aplicaciones.
• Proporciona el estado de cada tarea en la página de la lista de verificación de seguridad y bloquea la implementación de su aplicación si falla alguna tarea.
• Almacena un registro de auditoría del análisis de la configuración de seguridad y su estado en el momento de la implementación.

A continuación, se incluye un ejemplo de reporte de error generado por la tarea Verify security checklist (Verificar lista de verificación de seguridad) en el conducto de lanzamiento de DevOps:

1. SECURITY_ADMINISTRATORS : determinar quién es el responsable de esta lista de verificación
2. RULE_SECURITY_ANALYZER : eliminar las vulnerabilidades en el código personalizado
3. SECURITY_ALERTS : abordar las alertas de seguridad rápidamente
4. CONFIGURE_RULES : configurar las reglas según corresponda
5. PASSWORD_POLICY : configurar las políticas de seguridad de autenticación

Verifique los registros de implementación para obtener la lista completa de tareas fallidas.

En el conducto de lanzamiento de Deployment Manager (Gerente de implementación) de Pega, la tarea de verificación del cumplimiento del sistema de contención valida el puntaje de cumplimiento de la aplicación durante la implementación. La tarea de verificación del cumplimiento del sistema de contención devuelve un error si el cumplimiento del sistema de contención de la aplicación es inferior al puntaje de cumplimiento configurado. Pega recomienda un puntaje de cumplimiento de 97 o más para las aplicaciones de alto rendimiento.

El gerente de implementación ahora bloquea las implementaciones en los sistemas con un nivel de producción de 5 si el artefacto contiene flujos en borrador. Si el nivel de producción es inferior a 5, se muestra un mensaje de advertencia en la sección Deployment History and Reports, que indica que los flujos en borrador podrían provocar fallas en la producción.

Las reversiones en el nivel de aplicación ahora proporcionan un enfoque más detallado de los puntos de restauración, que puede usar para revertir reglas e instancias de datos en una aplicación específica. Esta función requiere Pega Platform 8.4 y posterior.

La reversión se basa en la función de puntos de restauración de Pega Platform™. La opción Rollback (Reversión) se le presenta al usuario solo cuando se produce un error en un paso de la implementación. Se genera automáticamente un punto de restauración cada vez que se produce una importación. Cualquier cambio que se produzca después de la importación y antes de que una aplicación genere el siguiente punto de restauración se revierte cuando la acción de reversión se dispara desde el conducto de lanzamiento.

La siguiente imagen muestra el diagrama de interacción de alto nivel del conducto de lanzamiento y el proceso involucrado en la reversión.

Las siguientes entradas de registro del conducto de lanzamiento del gerente de implementación se muestran cuando se produce la reversión:

Para las implementaciones manuales que usan el asistente de importación, use la herramienta prpcServiceUtils para revertir su sistema a un punto de restauración si surge algún problema durante la importación de un producto.

Pega Platform crea automáticamente puntos de restauración después de una importación de archivos. Al importar archivos de productos, no seleccione Do not set restore point or save metadata during the import. De lo contrario, la opción le permite a Pega crear un punto de restauración como parte de la importación del archivo de productos.

Limitaciones de los puntos de restauración

Existen limitaciones en cuanto a lo que se puede restaurar cuando se hace una reversión. Pega Platform usa registros históricos para devolver la mayor parte del sistema al estado del punto de restauración. Los cambios en los siguientes elementos no generan registros históricos, y la función de reversión no los revierte. Decida en cada caso si debe eliminar estos cambios manualmente o si pueden permanecer en el sistema.

• Cambios de SQL
• Importaciones de archivos .jar de Java
• Algunas instancias de datos personalizadas

Cuando configura la clase de un tipo de datos, puede especificar que no se genere un registro histórico para las instancias de ese tipo. Si la instancia de datos no genera un registro histórico, los cambios en la instancia de datos no pueden revertirse.
Puede especificar qué reglas e instancias de datos se devuelven al estado anterior:

• Sistema: revertir cada regla e instancia de datos con un registro histórico. Esta es la configuración predeterminada.
• Usuario: revertir la regla y las instancias de datos modificadas por un usuario específico. 
  Nota: Si más de un usuario cambia alguna regla, aparecerá un mensaje de error, y deberá usar la reversión del sistema.
• Aplicación: revertir la regla y las instancias de datos en una aplicación específica.

Para obtener más información sobre los puntos de restauración, consulte Uso de puntos de restauración para permitir la recuperación de errores.