Utilisation de la gestion du cycle de vie en tant qu'utilisateur du Blueprint

La gestion du cycle de vie est la capacité de régénérer une base de code à partir d'options ou de versions mises à jour d'un plan. Cela permet à l'auteur d'un plan de gérer de manière centralisée le cycle de développement logiciel de chaque projet contenant un plan spécifique. Par exemple, l'ajout d'un correctif de sécurité à un plan d'application Web permettra à chaque projet contenant ou créé à partir du plan d'application Web de récupérer automatiquement ce correctif. Ce même cadre de gestion vous permet également, en tant qu'utilisateur du plan, de modifier les options du plan une fois celles-ci sélectionnées.

Utilisation de la gestion du cycle de vie sur les projets existants

Vous pouvez utiliser la gestion du cycle de vie pour les projets créés à partir de plans ou pour des projets existants qui ne sont associés à aucun plan. Par exemple, vous pouvez ajouter un plan de pratiques de sécurité standard dans une application five-year-old Java qui n'a jamais été créée à partir d'un plan. Le plan génère un flux de travail d'analyse de sécurité et d'autres codes associés. Cette partie de la base de code de l'application Java sera désormais automatiquement mise à jour conformément aux meilleures pratiques de votre équipe chaque fois que des modifications sont apportées au plan.

Utilisation de la gestion du cycle de vie sur plusieurs plans d'un projet

Comme les plans représentent des composants architecturaux, plusieurs plans peuvent souvent être utilisés ensemble dans le même projet. Par exemple, un projet peut être composé d'un API plan Web central élaboré par un ingénieur de plate-forme de l'entreprise, ainsi que d'un plan de vérification des versions élaboré par l'équipe chargée de la sécurité des applications. Chacun de ces plans peut être mis à jour indépendamment et mémorisera les résolutions de fusion qui lui ont été appliquées dans le passé.

Note

En tant que composants architecturaux arbitraires, tous les plans n'ont pas de sens ensemble ou ne fonctionneront pas logiquement ensemble, même s'ils essaieront tout de même de se fondre les uns dans les autres.

Gérer les conflits liés au cycle de vie des pull requests

Parfois, les pull requests relatives au cycle de vie peuvent générer des conflits de fusion. Ces problèmes peuvent être résolus manuellement. Les résolutions sont mémorisées lors des mises à jour ultérieures du plan.

Se désinscrire des modifications apportées à la gestion du cycle de vie

Les utilisateurs peuvent supprimer un plan d'un projet pour dissocier toutes les références au plan et refuser les mises à jour du cycle de vie. Pour des raisons de sécurité, cela ne supprime ni n'affecte le code ou les ressources du projet, y compris ce qui a été ajouté à partir du plan. Pour plus d’informations, consultez Dissocier un plan d'un projet pour arrêter les mises à jour.

Remplacer la gestion du cycle de vie d'un plan dans un projet

Si vous souhaitez annuler les mises à jour d'un plan pour des fichiers spécifiques de votre projet, vous pouvez inclure un fichier de propriété dans votre référentiel. GitLabLa spécification Code Owners est la directive recommandée. Le plan respecte toujours le fichier du propriétaire du code par rapport à tout le reste et peut en générer un exemple comme celui-ci :

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/**',
            ],
          },
        ],
      },
    });

Cela génère un .ownership-file avec le contenu suivant :

[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/**