Amazon n' CodeCatalyst est plus ouvert aux nouveaux clients. Les clients existants peuvent continuer à utiliser le service normalement. Pour de plus amples informations, veuillez consulter Comment effectuer une migration depuis CodeCatalyst.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

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

La gestion du cycle de vie est la capacité à 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 vie de développement logiciel de chaque projet contenant un plan particulier. 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 qu'elles ont été 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 Java vieille de cinq ans 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 avec les 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 cadre d'un même projet. Par exemple, un projet peut être composé d'un plan d'API 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 de 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é.

Gestion des conflits dans les pull requests du cycle de vie

Les demandes d'extraction liées au cycle de vie peuvent parfois 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ésabonner 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 désactiver 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é depuis le plan. Pour de plus amples informations, veuillez consulter 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 des propriétaires de code par rapport à tout le reste et peut 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/**