Trabajar con la administración del ciclo de vida como usuario de blueprint - Amazon CodeCatalyst

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Trabajar con la administración del ciclo de vida como usuario de blueprint

La gestión del ciclo de vida es la capacidad de regenerar una base de código a partir de opciones o versiones actualizadas de un plan. Esto permite al autor de un plan gestionar de forma centralizada el ciclo de vida de desarrollo de software de cada proyecto que contenga un plan concreto. Por ejemplo, introducir una corrección de seguridad en el esquema de una aplicación web permitirá que todos los proyectos que contengan o se hayan creado a partir del esquema de la aplicación web recojan esa corrección automáticamente. Este mismo marco de administración también le permite, como usuario de un blueprint, cambiar las opciones del blueprint una vez seleccionadas.

Utilizar la gestión del ciclo de vida en los proyectos existentes

Puede utilizar la gestión del ciclo de vida para los proyectos creados a partir de planos o en proyectos existentes que no estén asociados a ningún plan. Por ejemplo, puede añadir un plan de prácticas de seguridad estándar a una aplicación five-year-old Java que nunca se haya creado a partir de un plan. El esquema genera un flujo de trabajo de escaneo de seguridad y otro código relacionado. Esa parte del código base de la aplicación Java ahora se actualizará automáticamente con las mejores prácticas de su equipo cada vez que se realicen cambios en el plan.

Utilizar la gestión del ciclo de vida en varios planos de un proyecto

Como los planos representan componentes arquitectónicos, a menudo se pueden usar varios planos juntos en el mismo proyecto. Por ejemplo, un proyecto podría estar compuesto por un API esquema web central creado por un ingeniero de plataformas de la empresa, junto con un plan de verificación de versiones creado por el equipo de seguridad de la aplicación. Cada uno de esos planos se puede actualizar de forma independiente y recordará las resoluciones de fusión que se les hayan aplicado en el pasado.

nota

Como componentes arquitectónicos arbitrarios, no todos los planos tienen sentido juntos ni funcionarán juntos de forma lógica, aunque sigan intentando fusionarse entre sí.

Trabajar con conflictos en el ciclo de vida de las solicitudes de cambios

En ocasiones, las solicitudes de extracción durante el ciclo de vida pueden generar conflictos de fusión. Estos se pueden resolver manualmente. Las resoluciones se recuerdan en las actualizaciones posteriores del plan.

Optar por no participar en los cambios en la administración del ciclo de vida

Los usuarios pueden eliminar un blueprint de un proyecto para disociar todas las referencias al blueprint y optar por no recibir actualizaciones del ciclo de vida. Por motivos de seguridad, esto no elimina ni afecta a ninguno de los recursos o códigos del proyecto, incluido lo que se agregó desde el plan. Para obtener más información, consulte Desasociar un blueprint de un proyecto para detener las actualizaciones.

Anular la gestión del ciclo de vida de un plan en un proyecto

Si desea anular las actualizaciones de un blueprint en archivos específicos de su proyecto, puede incluir un archivo de propiedad en su repositorio. GitLabLa especificación Code Owners es la guía recomendada. El plano siempre respeta el archivo de propietarios del código por encima de todo lo demás y puede generar uno de muestra como el siguiente:

new BlueprintOwnershipFile(sourceRepo, { resynthesis: { strategies: [ { identifier: 'dont-override-sample-code', description: 'This strategy is applied accross all sample code. The blueprint will create sample code, but skip attempting to update it.', strategy: MergeStrategies.neverUpdate, globs: [ '**/src/**', '**/css/**', ], }, ], }, });

Esto genera un .ownership-file con el siguiente contenido:

[dont-override-sample-code] @amazon-codecatalyst/blueprints.import-from-git # This strategy is applied accross all sample code. The blueprint will create sample code, but skip attempting to update it. # Internal merge strategy: neverUpdate **/src/** **/css/**