Amazon non CodeCatalyst è più aperta a nuovi clienti. I clienti esistenti possono continuare a utilizzare il servizio normalmente. Per ulteriori informazioni, consulta [Come migrare da CodeCatalyst](migration.md).

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Lavorare con la gestione del ciclo di vita come autore di progetti
<a name="lifecycle-management-dev"></a>

La gestione del ciclo di vita ti consente di mantenere sincronizzati un gran numero di progetti da un'unica fonte comune di best practice. Ciò consente di ridimensionare la propagazione delle correzioni e la manutenzione di un numero qualsiasi di progetti durante l'intero ciclo di vita di sviluppo del software. La gestione del ciclo di vita semplifica le campagne interne, le correzioni di sicurezza, gli audit, gli aggiornamenti di runtime, le modifiche alle migliori pratiche e altre pratiche di manutenzione perché tali standard sono definiti in un unico posto e aggiornati automaticamente a livello centrale quando vengono pubblicati nuovi standard.

Quando viene pubblicata una nuova versione del blueprint, a tutti i progetti che lo contengono viene richiesto di aggiornarsi alla versione più recente. In qualità di autore del blueprint, puoi anche vedere la versione di un particolare blueprint contenuta in ogni progetto per motivi di conformità. In caso di conflitti in un repository di origine esistente, la gestione del ciclo di vita crea richieste pull. Per tutte le altre risorse, come Dev Environment, tutti gli aggiornamenti della gestione del ciclo di vita creano esclusivamente nuove risorse. Gli utenti sono liberi di unire o meno tali richieste pull. Quando le richieste pull in sospeso vengono unite, la versione del blueprint, incluse le opzioni, utilizzata nel progetto viene quindi aggiornata. Per informazioni su come utilizzare la gestione del ciclo di vita come utente del blueprint, consulta e. [Utilizzo della gestione del ciclo di vita su progetti esistenti](lifecycle-management-user.md#using-lm-existing-projects) [Utilizzo della gestione del ciclo di vita su più blueprint in un progetto](lifecycle-management-user.md#using-lm-multiple-bp)

**Topics**
+ [Test della gestione del ciclo di vita per gli output di bundle e i conflitti di unione](test-lm.md)
+ [Utilizzo di strategie di unione per generare pacchetti e specificare file](merge-strategies-lm.md)
+ [Accesso agli oggetti contestuali per i dettagli del progetto](context-objects-lm.md)

# Test della gestione del ciclo di vita per gli output di bundle e i conflitti di unione
<a name="test-lm"></a>

Puoi testare localmente la gestione del ciclo di vita del tuo blueprint e unire la risoluzione dei conflitti. Nella `synth/` directory viene generata una serie di bundle che rappresentano le varie fasi di un aggiornamento del ciclo di vita. Per testare la gestione del ciclo di vita, puoi eseguire il seguente comando yarn sul tuo blueprint:. `yarn blueprint: resynth` Per saperne di più sulla risintesi e sui pacchetti, vedi e. [Risintesi](custom-bp-concepts.md#resynthesis-concept) [Generazione di file con risintesi](merge-strategies-lm.md#three-way-merge-lm)

# Utilizzo di strategie di unione per generare pacchetti e specificare file
<a name="merge-strategies-lm"></a>

È possibile utilizzare strategie di unione per generare pacchetti con risintesi e specificare file per gli aggiornamenti della gestione del ciclo di vita dei blueprint personalizzati. Sfruttando le strategie resythensis e merge, è possibile gestire gli aggiornamenti e controllare quali file vengono aggiornati durante le distribuzioni. Puoi anche scrivere strategie personalizzate per controllare il modo in cui le modifiche vengono unite ai progetti esistenti. CodeCatalyst 

**Topics**
+ [Generazione di file con risintesi](#three-way-merge-lm)
+ [Utilizzo di strategie di fusione](#vended-merge-strategies-lm)
+ [Specificazione dei file per gli aggiornamenti della gestione del ciclo di vita](#specify-files-lm-updates)
+ [Scrittura di strategie di fusione](#write-merge-strategies-lm)

## Generazione di file con risintesi
<a name="three-way-merge-lm"></a>

Resynthesis può unire il codice sorgente prodotto da un blueprint con il codice sorgente precedentemente generato dallo stesso blueprint, permettendo la propagazione delle modifiche a un blueprint ai progetti esistenti. Le unioni vengono eseguite dalla funzione tra i pacchetti di output del blueprint. `resynth()` Resynthesis genera innanzitutto tre pacchetti che rappresentano aspetti diversi del blueprint e dello stato del progetto. Può essere eseguito manualmente localmente con il `yarn blueprint:resynth` comando, che creerà i bundle se non esistono già. L'utilizzo manuale dei pacchetti ti consentirà di simulare e testare localmente il comportamento della risintesi. Per impostazione predefinita, i blueprint eseguono solo la risintesi tra i repository sottostanti, `src/*` poiché solo quella parte del pacchetto è in genere sotto il controllo del codice sorgente. Per ulteriori informazioni, consulta [Risintesi](custom-bp-concepts.md#resynthesis-concept).
+ `existing-bundle`- Questo pacchetto è una rappresentazione dello stato del progetto esistente. Questo è costruito artificialmente dal calcolo di sintesi per fornire al modello un contesto su cosa c'è nel progetto in cui viene implementato (se non altro). Se qualcosa esiste già in questa posizione quando si esegue la risintesi in locale, verrà ripristinato e considerato come una simulazione. Altrimenti, verrà impostato sul contenuto di. `ancestor-bundle`
+ `ancestor-bundle`- Questo è il pacchetto che rappresenta l'output del progetto se è stato sintetizzato con alcune opzioni e/o versioni precedenti. Se è la prima volta che questo blueprint viene aggiunto a un progetto, allora l'antenato non esiste, quindi è impostato sugli stessi contenuti di. `existing-bundle` A livello locale, se questo pacchetto esiste già in questa posizione, verrà rispettato come simulato.
+ `proposed-bundle`- Questo è il pacchetto che simula il modello se è stato sintetizzato con alcune nuove opzioni e/o versioni. Questo è lo stesso pacchetto che verrebbe prodotto dalla funzione. `synth()` A livello locale, questo pacchetto viene sempre sovrascritto.

Ogni pacchetto viene creato durante una fase di risintesi a cui è possibile accedere dalla classe blueprint sotto. `this.context.resynthesisPhase`
+ `resolved-bundle`- Questo è il pacchetto finale, che è una rappresentazione di ciò che viene impacchettato e distribuito in un progetto. CodeCatalyst È possibile visualizzare quali file e differenze vengono inviati ai meccanismi di distribuzione. Questo è l'output della `resynth()` funzione che risolve le fusioni tra gli altri tre pacchetti.

L'unione a tre vie viene applicata prendendo la differenza tra `ancestor-bundle` e `proposed-bundle` e aggiungendola a per generare il. `existing-bundle` `resolved-bundle` Tutte le strategie di unione risolvono i file in. `resolved-bundle` Resynthesis risolve la portata di questi pacchetti con le strategie di fusione del progetto `resynth()` e produce il pacchetto risolto a partire dal risultato.

## Utilizzo di strategie di fusione
<a name="vended-merge-strategies-lm"></a>

È possibile utilizzare una strategia di fusione fornita dalla libreria Blueprints. Queste strategie forniscono modi per risolvere gli output e i conflitti dei file menzionati nella sezione. [Generazione di file con risintesi](#three-way-merge-lm)
+ `alwaysUpdate`- Una strategia che si risolve sempre nel file proposto.
+ `neverUpdate`- Una strategia che si risolve sempre nel file esistente.
+ `onlyAdd`- Una strategia che si risolve nel file proposto quando un file esistente non esiste già. Altrimenti, si risolve nel file esistente.
+ `threeWayMerge`- Una strategia che esegue un'unione a tre vie tra i file predecessori esistenti, proposti e comuni. Il file risolto può contenere indicatori di conflitto se i file non possono essere uniti in modo pulito. Il contenuto dei file forniti deve essere codificato in UTF-8 affinché la strategia produca un output significativo. La strategia tenta di rilevare se i file di input sono binari. Se la strategia rileva un conflitto di fusione in un file binario, restituisce sempre il file proposto.
+ `preferProposed`- Una strategia che esegue un'unione a tre vie tra i file predecessori esistenti, proposti e comuni. Questa strategia risolve i conflitti selezionando il lato del file proposto di ogni conflitto.
+ `preferExisting`- Una strategia che esegue un'unione a tre vie tra i file predecessori esistenti, proposti e comuni. Questa strategia risolve i conflitti selezionando il lato del file esistente di ogni conflitto.

[Per visualizzare il codice sorgente per le strategie di fusione, consulta il repository open source. GitHub ](https://github.com/aws/codecatalyst-blueprints/blob/main/packages/blueprints/blueprint/src/resynthesis/merge-strategies/merge-strategies.ts#L17)

## Specificazione dei file per gli aggiornamenti della gestione del ciclo di vita
<a name="specify-files-lm-updates"></a>

Durante la risintesi, i blueprint controllano il modo in cui le modifiche vengono unite in un archivio di origine esistente. Tuttavia, potresti non voler inviare aggiornamenti a ogni singolo file del tuo blueprint. Ad esempio, il codice di esempio come i fogli di stile CSS deve essere specifico del progetto. La strategia di fusione a tre vie è l'opzione predefinita se non si specifica un'altra strategia. I blueprint possono specificare quali file possiedono e quali no specificando le strategie di unione sulla struttura del repository stesso. I blueprint possono aggiornare le proprie strategie di fusione e le strategie più recenti possono essere utilizzate durante la risintesi.

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

È possibile specificare più strategie di fusione e l'ultima strategia ha la precedenza. I file scoperti sono di default three-way-merge simili a Git. Il `MergeStrategies` costrutto fornisce diverse strategie di fusione, ma puoi scriverne di tue. Le strategie fornite aderiscono al driver di strategia [git merge](https://git-scm.com/docs/merge-strategies).

## Scrittura di strategie di fusione
<a name="write-merge-strategies-lm"></a>

Oltre a utilizzare una delle strategie di build merge fornite, puoi anche scrivere le tue strategie. Le strategie devono aderire a un'interfaccia strategica standard. È necessario scrivere una funzione strategica che acquisisca le versioni di un file da `existing-bundle` `proposed-bundle``ancestor-bundle`, e e le unisca in un unico file risolto. Per esempio:

```
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;
```

Se i file non esistono (non sono definiti), il percorso del file non esiste in quel particolare pacchetto di posizioni.

**Esempio:**

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

# Accesso agli oggetti contestuali per i dettagli del progetto
<a name="context-objects-lm"></a>

In qualità di autore del blueprint, puoi accedere al contesto del progetto del blueprint durante la sintesi per ottenere informazioni come lo spazio e i nomi dei progetti o i file esistenti nell'archivio dei sorgenti di un progetto. Puoi anche ottenere dettagli come la fase di risintesi generata dal blueprint. Ad esempio, puoi accedere al contesto per sapere se stai risintetizzando per generare un pacchetto predecessore o un pacchetto proposto. Il contesto di codice esistente può quindi essere utilizzato per trasformare il codice nel repository. Ad esempio, puoi scrivere la tua strategia di risintesi per impostare standard di codice specifici. La strategia può essere aggiunta al `blueprint.ts` file per piccoli progetti oppure è possibile creare un file separato per le strategie.

L'esempio seguente mostra come trovare file nel contesto di un progetto, impostare un generatore di flussi di lavoro e impostare una strategia di risintesi fornita da blueprint per un particolare file:

```
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));
    }
  }
```