Trabalhando com o gerenciamento do ciclo de vida como usuário do blueprint

O gerenciamento do ciclo de vida é a capacidade de regenerar uma base de código a partir de opções ou versões atualizadas de um blueprint. Isso permite que um autor do blueprint gerencie centralmente o ciclo de vida de desenvolvimento de software de cada projeto que contém um blueprint específico. Por exemplo, enviar uma correção de segurança para um blueprint de aplicativo web permitirá que cada projeto contendo ou criado a partir do blueprint de aplicativo web receba essa correção automaticamente. Essa mesma estrutura de gerenciamento também permite que você, como usuário do blueprint, altere as opções do blueprint após elas terem sido selecionadas.

Usando o gerenciamento do ciclo de vida em projetos existentes

Você pode usar o gerenciamento do ciclo de vida para projetos criados a partir de blueprints ou em projetos existentes não associados a nenhum blueprint. Por exemplo, você pode adicionar um blueprint de práticas de segurança padrão em um aplicativo five-year-old Java que nunca foi criado a partir de um blueprint. O blueprint gera um fluxo de trabalho de verificação de segurança e outros códigos relacionados. Essa parte da base de código no aplicativo Java agora será atualizada automaticamente com as melhores práticas da sua equipe sempre que forem feitas alterações no blueprint.

Usando o gerenciamento do ciclo de vida em vários esquemas em um projeto

Como os blueprints representam componentes arquitetônicos, vários blueprints geralmente podem ser usados juntos no mesmo projeto. Por exemplo, um projeto pode ser composto por um API plano central da web criado por um engenheiro de plataforma da empresa, junto com um plano de verificação de lançamento criado pela equipe de segurança do aplicativo. Cada um desses esquemas pode ser atualizado de forma independente e lembrará as resoluções de mesclagem aplicadas a eles no passado.

nota

Como componentes arquitetônicos arbitrários, nem todos os projetos fazem sentido juntos ou funcionarão logicamente juntos, mesmo que ainda tentem se fundir.

Trabalhando com conflitos em pull requests do ciclo de vida

Ocasionalmente, pull requests do ciclo de vida podem gerar conflitos de mesclagem. Eles podem ser resolvidos manualmente. As resoluções são lembradas nas atualizações subsequentes do blueprint.

Optando por não participar das mudanças no gerenciamento do ciclo de vida

Os usuários podem remover um blueprint de um projeto para dissociar todas as referências ao blueprint e optar por não receber atualizações do ciclo de vida. Por motivos de segurança, isso não remove nem afeta nenhum código ou recursos do projeto, incluindo o que foi adicionado do blueprint. Para obter mais informações, consulte Desassociando um blueprint de um projeto para interromper as atualizações.

Substituindo o gerenciamento do ciclo de vida de um blueprint em um projeto

Se quiser substituir as atualizações de um blueprint em arquivos específicos em seu projeto, você pode incluir um arquivo de propriedade em seu repositório. GitLabA especificação do Code Owners é a diretriz recomendada. O blueprint sempre respeita o arquivo do proprietário do código acima de tudo e pode gerar uma amostra como a seguinte:

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

Isso gera um .ownership-file com o seguinte conteúdo:

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