A Amazon não CodeCatalyst está mais aberta a novos clientes. Os clientes atuais podem continuar usando o serviço normalmente. Para obter mais informações, consulte [Como migrar do CodeCatalyst](migration.md).

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Trabalho com o gerenciamento do ciclo de vida como autor do esquema
<a name="lifecycle-management-dev"></a>

O gerenciamento do ciclo de vida permite que você mantenha um grande número de projetos sincronizados a partir de uma única fonte comum de práticas recomendadas. Isso escala a propagação de correções e a manutenção de qualquer número de projetos em todo o ciclo de vida de desenvolvimento de software. O gerenciamento do ciclo de vida simplifica campanhas internas, correções de segurança, auditorias, atualizações de runtime, alterações nas práticas recomendadas e outras práticas de manutenção porque esses padrões são definidos em um só lugar e automaticamente atualizados de modo centralizado quando novos padrões são publicados.

Quando uma nova versão do esquema é publicada, todos os projetos que contêm esse esquema são solicitados a atualizar para a versão mais recente. Como autor do esquema, você também pode ver a versão de um determinado esquema que cada projeto contém para fins de conformidade. Quando há conflitos em um repositório de origem existente, o gerenciamento do ciclo de vida cria solicitações pull. Para todos os outros recursos, como o Ambiente de Desenvolvimento, todas as atualizações de gerenciamento do ciclo de vida criam estritamente novos recursos. Os usuários são livres para mesclar ou não essas solicitações pull. Quando as solicitações pull pendentes são mescladas, a versão do esquema, incluindo as opções, usada no projeto é atualizada. Para saber mais sobre como trabalhar com o gerenciamento do ciclo de vida como usuário do esquema, consulte [Usar o gerenciamento do ciclo de vida em projetos existentes](lifecycle-management-user.md#using-lm-existing-projects) e [Usar o gerenciamento do ciclo de vida em vários esquemas em um projeto](lifecycle-management-user.md#using-lm-multiple-bp).

**Topics**
+ [Teste do gerenciamento do ciclo de vida para saídas de pacotes e conflitos de mesclagem](test-lm.md)
+ [Uso de estratégias de mesclagem para gerar pacotes e especificar arquivos](merge-strategies-lm.md)
+ [Acesso a objetos de contexto para saber detalhes do projeto](context-objects-lm.md)

# Teste do gerenciamento do ciclo de vida para saídas de pacotes e conflitos de mesclagem
<a name="test-lm"></a>

Você pode testar localmente o gerenciamento do ciclo de vida do seu esquema e mesclar a resolução de conflitos. Uma série de pacotes no diretório `synth/` que representam as várias fases de uma atualização do ciclo de vida é gerada. Para testar o gerenciamento do ciclo de vida, execute o seguinte comando yarn em seu esquema: `yarn blueprint: resynth`. Para saber mais sobre ressíntese e pacotes, consulte e. [Ressíntese](custom-bp-concepts.md#resynthesis-concept) [Gerar arquivos com ressíntese](merge-strategies-lm.md#three-way-merge-lm)

# Uso de estratégias de mesclagem para gerar pacotes e especificar arquivos
<a name="merge-strategies-lm"></a>

Você pode usar estratégias de mesclagem para gerar pacotes com ressíntese e especificar arquivos para atualizações de gerenciamento do ciclo de vida de esquemas personalizados. Ao aproveitar as estratégias de ressíntese e mesclagem, você pode gerenciar atualizações e controlar quais arquivos são atualizados durante as implantações. Você também pode escrever suas próprias estratégias para controlar como as alterações são mescladas aos projetos existentes do CodeCatalyst.

**Topics**
+ [Gerar arquivos com ressíntese](#three-way-merge-lm)
+ [Usar estratégias de mesclagem](#vended-merge-strategies-lm)
+ [Especificação de arquivos para atualizações de gerenciamento do ciclo de vida](#specify-files-lm-updates)
+ [Escrita de estratégias de mesclagem](#write-merge-strategies-lm)

## Gerar arquivos com ressíntese
<a name="three-way-merge-lm"></a>

A ressíntese pode mesclar o código-fonte produzido por um esquema com o código-fonte que foi gerado anteriormente pelo mesmo esquema, permitindo que as alterações em um esquema sejam propagadas para projetos existentes. As mesclagens são executadas a partir da função `resynth()` nos pacotes de saída do esquema. A ressíntese primeiro gera três pacotes que representam diferentes aspectos do esquema e do estado do projeto. Ela pode ser executada manualmente no local com o comando `yarn blueprint:resynth`, que criará os pacotes se eles ainda não existirem. Trabalhar manualmente com os pacotes permitirá que você simule e teste o comportamento da ressíntese localmente. Por padrão, os esquemas só executam a ressíntese nos repositórios em `src/*`, já que somente essa parte do pacote normalmente está sob controle de origem. Para obter mais informações, consulte [Ressíntese](custom-bp-concepts.md#resynthesis-concept).
+ `existing-bundle` - Esse pacote é uma representação do estado existente do projeto. Ele é construído artificialmente pela computação de síntese para fornecer ao esquema um contexto sobre o que está no projeto em que está sendo implantado (se houver). Se algo já existir nesse local ao executar a ressíntese localmente, ele será redefinido e respeitado como uma simulação. Caso contrário, ele será definido como o conteúdo do `ancestor-bundle`.
+ `ancestor-bundle` - Esse é o pacote que representa a saída do esquema se tiver sido sintetizado com algumas opções e/ou versões anteriores. Se for a primeira vez que esse esquema está sendo adicionado a um projeto, o ancestral não existe, e ele está definido com o mesmo conteúdo do `existing-bundle`. Localmente, se esse pacote já existir, ele será respeitado como uma simulação.
+ `proposed-bundle` - Esse é o pacote que simula o esquema se tiver sido sintetizado com algumas novas opções e/ou versões. Esse é o mesmo pacote que seria produzido pela função `synth()`. Localmente, esse pacote sempre é substituído.

Cada pacote é criado durante uma fase de ressíntese que pode ser acessada a partir da classe de esquema em `this.context.resynthesisPhase`.
+ `resolved-bundle` - Esse é o pacote final, que é uma representação do que é empacotado e implantado em um projeto do CodeCatalyst. Você pode ver quais arquivos e diffs são enviados para os mecanismos de implantação. Essa é a saída da função `resynth()` que resolve mesclagens entre os outros três pacotes.

A mesclagem de três vias é aplicada tomando a diferença entre o `ancestor-bundle` e `proposed-bundle` e adicionando-a ao `existing-bundle` para gerar o `resolved-bundle`. Todas as estratégias de mesclagem resolvem arquivos para o `resolved-bundle`. A ressíntese resolve o alcance desses pacotes com as estratégias de mesclagem do esquema durante `resynth()` e produz o pacote resolvido no resultado.

## Usar estratégias de mesclagem
<a name="vended-merge-strategies-lm"></a>

Você pode usar uma estratégia de mesclagem oferecida pela biblioteca de esquemas. Essas estratégias fornecem maneiras de resolver saídas de arquivos e conflitos para arquivos mencionados na seção [Gerar arquivos com ressíntese](#three-way-merge-lm).
+ `alwaysUpdate` - Uma estratégia que sempre se resolve com o arquivo proposto.
+ `neverUpdate` - Uma estratégia que sempre se resolve com o arquivo existente.
+ `onlyAdd` - Uma estratégia que se resolve com o arquivo proposto quando um arquivo existente ainda não existe. Caso contrário, se resolve com o arquivo existente.
+ `threeWayMerge` - Uma estratégia que executa uma fusão tripla entre os arquivos ancestrais existentes, propostos e comuns. O arquivo resolvido pode conter marcadores de conflito se os arquivos não puderem ser mesclados de forma limpa. O conteúdo dos arquivos fornecidos deve ser codificado em UTF-8 para que a estratégia produza uma saída significativa. A estratégia tenta detectar se os arquivos de entrada são binários. Se a estratégia detectar um conflito de mesclagem em um arquivo binário, ela sempre retornará o arquivo proposto.
+ `preferProposed` - Uma estratégia que executa uma fusão tripla entre os arquivos ancestrais existentes, propostos e comuns. Essa estratégia resolve conflitos selecionando o lado do arquivo proposto de cada conflito.
+ `preferExisting` - Uma estratégia que executa uma fusão tripla entre os arquivos ancestrais existentes, propostos e comuns. Essa estratégia resolve conflitos selecionando o lado do arquivo existente de cada conflito.

Para ver o código-fonte das estratégias de mesclagem, consulte o [repositório de código aberto do GitHub](https://github.com/aws/codecatalyst-blueprints/blob/main/packages/blueprints/blueprint/src/resynthesis/merge-strategies/merge-strategies.ts#L17).

## Especificação de arquivos para atualizações de gerenciamento do ciclo de vida
<a name="specify-files-lm-updates"></a>

Durante a ressíntese, os esquemas controlam como as alterações são mescladas em um repositório de origem existente. No entanto, você talvez não queira enviar atualizações para todos os arquivos do seu esquema. Por exemplo, códigos de exemplo, como folhas de estilo CSS, devem ser específicos do projeto. A estratégia de mesclagem de três vias é a opção padrão se você não especificar outra estratégia. Os esquemas podem especificar quais arquivos possuem e quais não possuem, especificando estratégias de mesclagem no próprio constructo do repositório. Os esquemas podem atualizar as estratégias de mesclagem, e as estratégias mais recentes podem ser usadas durante a ressíntese.

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

Várias estratégias de mesclagem podem ser especificadas, e a última estratégia tem precedência. Os arquivos descobertos usam como padrão uma mesclagem de três vias semelhante ao Git. Existem várias estratégias de mesclagem fornecidas por meio do constructo `MergeStrategies`, mas você pode escrever a sua própria. As estratégias fornecidas seguem o driver de [estratégia de mesclagem do Git](https://git-scm.com/docs/merge-strategies).

## Escrita de estratégias de mesclagem
<a name="write-merge-strategies-lm"></a>

Além de usar uma das estratégias de mescla de compilações fornecidas, você também pode escrever suas próprias estratégias. As estratégias devem seguir uma interface padrão. Você deve escrever uma função de estratégia que pegue versões de um arquivo do `existing-bundle`, do `proposed-bundle` e do `ancestor-bundle`, e mesclá-las em um único arquivo resolvido. Por exemplo:

```
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 os arquivos não existirem (forem indefinidos), esse caminho de arquivo não existirá nesse pacote de localização específico.

**Exemplo de**:

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

# Acesso a objetos de contexto para saber detalhes do projeto
<a name="context-objects-lm"></a>

Como autor do esquema, você pode acessar o contexto do projeto do esquema durante a síntese para ter informações, como espaço e nomes de projetos, ou arquivos existentes no repositório de origem de um projeto. Você também pode saber detalhes, como a fase de ressíntese que o esquema está gerando. Por exemplo, você pode acessar o contexto para saber se está ressintetizando para gerar um pacote ancestral ou um pacote proposto. O contexto de código existente pode ser usado para transformar o código em seu repositório. Por exemplo, você pode escrever sua própria estratégia de ressíntese para definir padrões de código específicos. A estratégia pode ser adicionada ao arquivo `blueprint.ts` para pequenos esquemas, ou você pode criar um arquivo separado para estratégias.

O exemplo a seguir mostra como você pode encontrar arquivos no contexto de um projeto, definir um criador de fluxo de trabalho e definir uma estratégia de ressíntese fornecida por um esquema para um arquivo específico:

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