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](migration.md).

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.

# Travailler avec la gestion du cycle de vie en tant qu'auteur de plans
<a name="lifecycle-management-dev"></a>

La gestion du cycle de vie vous permet de synchroniser un grand nombre de projets à partir d'une source commune unique de meilleures pratiques. Cela permet d'échelonner la propagation des correctifs et la maintenance d'un certain nombre de projets tout au long de leur cycle de vie de développement logiciel. La gestion du cycle de vie rationalise les campagnes internes, les correctifs de sécurité, les audits, les mises à niveau d'exécution, les modifications des meilleures pratiques et les autres pratiques de maintenance, car ces normes sont définies en un seul endroit et mises à jour automatiquement de manière centralisée lorsque de nouvelles normes sont publiées.

Lorsqu'une nouvelle version de votre plan est publiée, tous les projets contenant ce plan sont invités à passer à la dernière version. En tant qu'auteur d'un plan, vous pouvez également consulter la version d'un plan spécifique que contient chaque projet à des fins de conformité. En cas de conflit dans un référentiel source existant, la gestion du cycle de vie crée des pull requests. Pour toutes les autres ressources, telles que l'environnement de développement, toutes les mises à jour de gestion du cycle de vie créent strictement de nouvelles ressources. Les utilisateurs sont libres de fusionner ou de ne pas fusionner ces pull requests. Lorsque les pull requests en attente sont fusionnées, la version du plan, y compris les options, utilisée dans votre projet est ensuite mise à jour. Pour en savoir plus sur l'utilisation de la gestion du cycle de vie en tant qu'utilisateur du Blueprint, consultez [Utilisation de la gestion du cycle de vie sur les projets existants](lifecycle-management-user.md#using-lm-existing-projects) et[Utilisation de la gestion du cycle de vie sur plusieurs plans d'un projet](lifecycle-management-user.md#using-lm-multiple-bp).

**Topics**
+ [Tester la gestion du cycle de vie pour détecter les sorties groupées et les conflits de fusion](test-lm.md)
+ [Utilisation de stratégies de fusion pour générer des ensembles et spécifier des fichiers](merge-strategies-lm.md)
+ [Accès aux objets contextuels pour les détails du projet](context-objects-lm.md)

# Tester la gestion du cycle de vie pour détecter les sorties groupées et les conflits de fusion
<a name="test-lm"></a>

Vous pouvez tester localement la gestion du cycle de vie de votre plan et fusionner la résolution des conflits. Dans le `synth/` répertoire, une série de bundles représentant les différentes phases d'une mise à jour du cycle de vie est générée. Pour tester la gestion du cycle de vie, vous pouvez exécuter la commande yarn suivante sur votre plan :`yarn blueprint: resynth`. Pour en savoir plus sur la resynthèse et les bundles, consultez et. [Resynthèse](custom-bp-concepts.md#resynthesis-concept) [Génération de fichiers par resynthèse](merge-strategies-lm.md#three-way-merge-lm)

# Utilisation de stratégies de fusion pour générer des ensembles et spécifier des fichiers
<a name="merge-strategies-lm"></a>

Vous pouvez utiliser des stratégies de fusion pour générer des ensembles avec resynthèse et spécifier des fichiers pour les mises à jour de gestion du cycle de vie des plans personnalisés. En tirant parti des stratégies de resythensis et de fusion, vous pouvez gérer les mises à jour et contrôler les fichiers mis à jour lors des déploiements. Vous pouvez également rédiger vos propres stratégies pour contrôler la manière dont les modifications sont fusionnées dans les CodeCatalyst projets existants.

**Topics**
+ [Génération de fichiers par resynthèse](#three-way-merge-lm)
+ [Utilisation de stratégies de fusion](#vended-merge-strategies-lm)
+ [Spécification de fichiers pour les mises à jour de gestion du cycle](#specify-files-lm-updates)
+ [Rédaction de stratégies de fusion](#write-merge-strategies-lm)

## Génération de fichiers par resynthèse
<a name="three-way-merge-lm"></a>

La resynthèse peut fusionner le code source produit par un plan avec le code source précédemment généré par le même plan, ce qui permet de propager les modifications apportées à un plan aux projets existants. Les fusions sont exécutées à partir de la `resynth()` fonction sur les ensembles de sortie du plan. La resynthèse génère d'abord trois ensembles représentant différents aspects du plan et de l'état du projet. Il peut être exécuté manuellement localement à l'aide de la `yarn blueprint:resynth` commande, qui créera les bundles s'ils n'existent pas déjà. Travailler manuellement avec les ensembles vous permettra de simuler et de tester le comportement de resynthèse localement. Par défaut, les plans exécutent uniquement la resynthèse dans les référentiels situés sous, `src/*` car seule cette partie du bundle est généralement contrôlée par le code source. Pour de plus amples informations, veuillez consulter [Resynthèse](custom-bp-concepts.md#resynthesis-concept).
+ `existing-bundle`- Ce bundle est une représentation de l'état actuel du projet. Ceci est construit artificiellement par le calcul de synthèse pour donner au plan le contexte du contenu du projet dans lequel il est déployé (le cas échéant). Si quelque chose existe déjà à cet endroit lors de l'exécution de la resynthèse localement, il sera réinitialisé et considéré comme une maquette. Dans le cas contraire, il sera réglé sur le contenu du`ancestor-bundle`.
+ `ancestor-bundle`- Il s'agit du bundle qui représente le résultat du plan s'il a été synthétisé avec certaines options et/ou versions précédentes. Si c'est la première fois que ce plan est ajouté à un projet, cela signifie que l'ancêtre n'existe pas. Il est donc défini sur le même contenu que le`existing-bundle`. Localement, si ce bundle existe déjà à cet endroit, il sera considéré comme une maquette.
+ `proposed-bundle`- Il s'agit du bundle qui se moque du plan s'il a été synthétisé avec de nouvelles options et/ou versions. Il s'agit du même bundle qui serait produit par la `synth()` fonction. Localement, ce bundle est toujours remplacé.

Chaque bundle est créé lors d'une phase de resynthèse accessible à partir de la classe Blueprint ci-dessous. `this.context.resynthesisPhase`
+ `resolved-bundle`- Il s'agit du bundle final, qui est une représentation de ce qui est empaqueté et déployé dans un CodeCatalyst projet. Vous pouvez voir quels fichiers et différences sont envoyés aux mécanismes de déploiement. Il s'agit du résultat de la `resynth()` fonction résolvant les fusions entre les trois autres ensembles.

La fusion à trois voies est appliquée en prenant la différence entre le `ancestor-bundle` et `proposed-bundle` et en l'ajoutant au `existing-bundle` pour générer le`resolved-bundle`. Toutes les stratégies de fusion résolvent les fichiers au format`resolved-bundle`. La resynthèse résout la portée de ces ensembles grâce aux stratégies de fusion du plan pendant le processus `resynth()` et produit le bundle résolu à partir du résultat.

## Utilisation de stratégies de fusion
<a name="vended-merge-strategies-lm"></a>

Vous pouvez utiliser une stratégie de fusion proposée par la bibliothèque de plans. Ces stratégies fournissent des moyens de résoudre les sorties de fichiers et les conflits pour les fichiers mentionnés dans la [Génération de fichiers par resynthèse](#three-way-merge-lm) section.
+ `alwaysUpdate`- Une stratégie qui correspond toujours au fichier proposé.
+ `neverUpdate`- Une stratégie qui résout toujours le problème avec le fichier existant.
+ `onlyAdd`- Une stratégie qui prend en compte le fichier proposé lorsqu'un fichier existant n'existe pas déjà. Dans le cas contraire, il est résolu dans le fichier existant.
+ `threeWayMerge`- Une stratégie qui effectue une fusion à trois voies entre les fichiers d'ancêtres existants, proposés et communs. Le fichier résolu peut contenir des marqueurs de conflit si les fichiers ne peuvent pas être correctement fusionnés. Le contenu des fichiers fournis doit être codé en UTF-8 pour que la stratégie produise un résultat significatif. La stratégie tente de détecter si les fichiers d'entrée sont binaires. Si la stratégie détecte un conflit de fusion dans un fichier binaire, elle renvoie toujours le fichier proposé.
+ `preferProposed`- Une stratégie qui effectue une fusion à trois voies entre les fichiers d'ancêtres existants, proposés et communs. Cette stratégie permet de résoudre les conflits en sélectionnant la version du fichier proposé pour chaque conflit.
+ `preferExisting`- Une stratégie qui effectue une fusion à trois voies entre les fichiers d'ancêtres existants, proposés et communs. Cette stratégie permet de résoudre les conflits en sélectionnant le côté du fichier existant dans chaque conflit.

Pour consulter le code source des stratégies de fusion, consultez le [ GitHub référentiel open source](https://github.com/aws/codecatalyst-blueprints/blob/main/packages/blueprints/blueprint/src/resynthesis/merge-strategies/merge-strategies.ts#L17).

## Spécification de fichiers pour les mises à jour de gestion du cycle
<a name="specify-files-lm-updates"></a>

Lors de la resynthèse, les plans contrôlent la manière dont les modifications sont fusionnées dans un référentiel source existant. Cependant, il se peut que vous ne souhaitiez pas envoyer des mises à jour à chaque fichier de votre plan. Par exemple, les exemples de code tels que les feuilles de style CSS sont conçus pour être spécifiques au projet. La stratégie de fusion à trois voies est l'option par défaut si vous ne spécifiez aucune autre stratégie. Les plans peuvent spécifier les fichiers qu'ils possèdent et ceux qu'ils ne possèdent pas en spécifiant des stratégies de fusion dans la structure du référentiel elle-même. Les plans peuvent mettre à jour leurs stratégies de fusion, et les dernières stratégies peuvent être utilisées lors de la resynthèse.

```
const sourceRepo = new SourceRepository(this, {
      title: 'my-repo',
    });
    sourceRepo.setResynthStrategies([
      {
        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/**',
        ],
      },
    ]);
```

Plusieurs stratégies de fusion peuvent être spécifiées, la dernière étant prioritaire. Les fichiers non couverts sont par défaut three-way-merge similaires à Git. Plusieurs stratégies de fusion sont proposées dans le `MergeStrategies` build, mais vous pouvez écrire la vôtre. Les stratégies fournies sont conformes au pilote de [stratégie git merge](https://git-scm.com/docs/merge-strategies).

## Rédaction de stratégies de fusion
<a name="write-merge-strategies-lm"></a>

En plus d'utiliser l'une des stratégies de build merge fournies, vous pouvez également écrire vos propres stratégies. Les stratégies doivent respecter une interface de stratégie standard. Vous devez écrire une fonction de stratégie qui prend les versions d'un fichier à partir du `existing-bundle``proposed-bundle`, et`ancestor-bundle`, et les fusionne en un seul fichier résolu. Par exemple :

```
type StrategyFunction = (
   /**
   * file from the ancestor bundle (if it exists)
   */
    commonAncestorFile: ContextFile | undefined, 
   /**
   * file from the existing bundle (if it exists)
   */
    existingFile: ContextFile | undefined,
   /**
   * file from the proposed bundle (if it exists)
   */ 
    proposedFile: ContextFile | undefined, 
    options?: {}) 
    /**
    * Return: file you'd like in the resolved bundle
    * passing undefined will delete the file from the resolved bundle
    */ 
=> ContextFile | undefined;
```

Si les fichiers n'existent pas (ne sont pas définis), ce chemin de fichier n'existe pas dans cet ensemble d'emplacements en particulier.

**Exemple :**

```
strategies: [
          {
            identifier: 'dont-override-sample-code',
            description: 'This strategy is applied across all sample code. The blueprint will create sample code, but skip attempting to update it.',
            strategy: (ancestor, existing, proposed) => {
                const resolvedfile = ...
                ...
                // do something
                ...
                return resolvedfile
            },
            globs: [
              '**/src/**',
              '**/css/**',
            ],
          },
        ],
```

# Accès aux objets contextuels pour les détails du projet
<a name="context-objects-lm"></a>

En tant qu'auteur d'un plan, vous pouvez accéder au contexte du projet du plan pendant la synthèse pour obtenir des informations telles que l'espace et les noms de projet, ou les fichiers existants dans le référentiel source d'un projet. Vous pouvez également obtenir des détails tels que la phase de resynthèse générée par le plan. Par exemple, vous pouvez accéder au contexte pour savoir si vous effectuez une resynthèse pour générer un bundle d'ancêtres ou un bundle proposé. Le contexte de code existant peut ensuite être utilisé pour transformer votre code dans votre référentiel. Par exemple, vous pouvez écrire votre propre stratégie de resynthèse pour définir des normes de code spécifiques. La stratégie peut être ajoutée au `blueprint.ts` fichier pour les petits plans, ou vous pouvez créer un fichier distinct pour les stratégies.

L'exemple suivant montre comment rechercher des fichiers dans le contexte d'un projet, définir un générateur de flux de travail et définir une stratégie de resynthèse basée sur un plan pour un fichier particulier :

```
const contextFiles = this.context.project.src.findAll({
      fileGlobs: ['**/package.json'],
    });

    // const workflows = this.context.project.src.findAll({
    //   fileGlobs: ['**/.codecatalyst/**.yaml'],
    // });

    const security = new WorkflowBuilder(this, {
      Name: 'security-workflow',
    });
    new Workflow(this, repo, security.getDefinition());
    repo.setResynthStrategies([
      {
        identifier: 'force-security',
        globs: ['**/.codecatalyst/security-workflow.yaml'],
        strategy: MergeStrategies.alwaysUpdate,
      },
    ]);


    for (const contextFile of contextFiles) {
      const packageObject = JSON.parse(contextFile.buffer.toString());
      new SourceFile(internalRepo, contextFile.path, JSON.stringify({
        ...packageObject,
      }, null, 2));
    }
  }
```