Implantar o código

Implantação do código com o Cloud Manager

Depois de configurar o Pipeline de produção (repositório, ambiente e ambiente de teste), você estará pronto para implantar seu código.

1. Clique em Implantar no Cloud Manager para iniciar o processo de implantação.

   

2. O Execução de pipeline será exibida.

   Clique em Criar para iniciar o processo.

   

3. O processo de build completo implanta seu código.

   Os seguintes estágios estão envolvidos no processo de criação:

   1. Implantação do Estágio
   2. Teste de preparo
   3. Implantação de produção
   OBSERVAÇÃO

   Além disso, você pode revisar as etapas de vários processos de implantação exibindo registros ou revisando resultados para os critérios de teste.

   A Implantação do preparo envolve estas etapas:

   • Validação: Essa etapa garante que o pipeline esteja configurado para usar os recursos disponíveis no momento, por exemplo, que a ramificação configurada exista, os ambientes estarão disponíveis.
   • Teste de compilação e unidade: Essa etapa executa um processo de criação contêiner. Consulte Compreensão do ambiente de criação para obter detalhes sobre o ambiente de criação.
   • Verificação de código: Esta etapa avalia a qualidade do código de seu aplicativo. Consulte Entender os resultados de teste para obter detalhes sobre o processo de teste.
   • Implantar no Estágio

   

   O Teste de preparo envolve as seguintes etapas:

   • Teste de segurança: Esta etapa avalia o impacto na segurança do código de seu aplicativo no ambiente de AEM. Consulte Entender os resultados de teste para obter detalhes sobre o processo de teste.
   • Teste de desempenho: Esta etapa avalia o desempenho do código do aplicativo. Consulte Entender os resultados de teste para obter detalhes sobre o processo de teste.

   

   O Implantação de produção envolve as seguintes etapas:

   • Pedido de aprovação (se estiver habilitado)
   • Agendar implantação de produção (se estiver habilitado)
   • Suporte CSE (se estiver habilitado)
   • Implantar na produção

   

   OBSERVAÇÃO

   O Agendar implantação de produção está ativado ao configurar o pipeline.

   Com essa opção, você pode agendar a implantação de produção ou clicar em Agora para executar a implantação de produção imediatamente.

   A data e a hora programadas são especificadas em termos de fuso horário do usuário.

   Clique em Confirmar para verificar suas configurações.

   

   Depois de confirmar o agendamento da implantação, a implantação do código é concluída.

   A tela a seguir é exibida quando Agora é selecionada na etapa acima.

   

Tempos limite

As etapas a seguir atingirão o tempo limite se forem deixadas aguardando o feedback do usuário:

Processo de implantação

A seção a seguir descreve como os pacotes de AEM e dispatcher são implantados na fase de estágio e na fase de produção.

O Cloud Manager carrega todos os arquivos target/*.zip produzidos pelo processo de compilação em um local de armazenamento. Esses artefatos são recuperados desse local durante as fases de implantação do pipeline.

Quando o Cloud Manager é implantado em topologias que não são de produção, o objetivo é concluir a implantação o mais rápido possível e, portanto, os artefatos são implantados em todos os nós simultaneamente da seguinte maneira:

1. O Cloud Manager determina se cada artefato é um pacote de AEM ou dispatcher.

2. O Cloud Manager remove todos os dispatchers do Balanceador de Carga para isolar o ambiente durante a implantação.

   A menos que configurado de outra forma, você pode ignorar as Alterações no Balanceador de Carga nas Implantações de Desenvolvimento e Estágio, ou seja, desanexar e anexar etapas em pipelines não de produção, para ambientes de desenvolvimento e o pipeline de produção, para ambientes de preparo.

   

   OBSERVAÇÃO

   Espera-se que esse recurso seja usado principalmente por clientes 1-1-1.

3. Cada artefato de AEM é implantado em cada instância AEM por meio de APIs do Gerenciador de Pacotes, com dependências de pacote determinando a ordem de implantação.

   Para saber mais sobre como usar pacotes para instalar novas funcionalidades, transferir conteúdo entre instâncias e fazer backup do conteúdo do repositório, consulte Como trabalhar com pacotes.

   OBSERVAÇÃO

   Todos os artefatos AEM são implantados tanto no autor quanto nos editores. Os run-modes devem ser usados quando configurações específicas a nós são necessárias. Para saber mais sobre como os run-modes permitem ajustar a instância de AEM para uma finalidade específica, consulte Modos de Execução.

4. O artefato do dispatcher é implantado em cada dispatcher da seguinte maneira:

   1. O backup das configurações atuais é feito e copiado para um local temporário
   2. Todas as configurações são excluídas, exceto os arquivos imutáveis. Consulte Gerenciar suas configurações do Dispatcher para obter mais detalhes. Isso limpa os diretórios para garantir que nenhum arquivo órfão seja deixado para trás.
   3. O artefato é extraído para o httpd diretório. Arquivos imutáveis não são substituídos. Quaisquer alterações feitas em arquivos imutáveis no repositório Git serão ignoradas no momento da implantação. Esses arquivos são fundamentais para a estrutura do AMS Dispatcher e não podem ser alterados.
   4. O Apache executa um teste de configuração. Se nenhum erro for encontrado, o serviço será recarregado. Se ocorrer um erro, as configurações serão restauradas a partir do backup, o serviço será recarregado e o erro será relatado ao Cloud Manager.
   5. Cada caminho especificado na configuração do pipeline é invalidado ou liberado do cache do dispatcher.
   OBSERVAÇÃO

   O Cloud Manager espera que o artefato do dispatcher contenha o conjunto completo de arquivos. Todos os arquivos de configuração do dispatcher devem estar presentes no repositório Git. Arquivos ou pastas ausentes resultarão em falha na implantação.

5. Após a implantação bem-sucedida de todos os pacotes de AEM e dispatcher em todos os nós, os dispatchers serão adicionados novamente ao balanceador de carga e a implantação será concluída.

   OBSERVAÇÃO

   É possível ignorar as alterações do Balanceador de Carga nas implantações de desenvolvimento e estágio, ou seja, desanexar e anexar etapas em pipelines não relacionados à produção, para ambientes do desenvolvedor e no pipeline de produção, para ambientes de preparo.

Implantação para fase de produção

O processo de implantação das topologias de produção é um pouco diferente para minimizar o impacto para AEM visitantes do Site.

As implantações de produção geralmente seguem as mesmas etapas descritas acima, mas de maneira contínua:

1. Implantar pacotes de AEM para o autor.
2. Desanexar dispatcher1 do balanceador de carga.
3. Implante pacotes de AEM para publish1 e o pacote do dispatcher para dispatcher1 em paralelo, liberar o cache do dispatcher.
4. Coloque o dispatcher1 de volta no balanceador de carga.
5. Depois que o dispatcher1 estiver novamente em serviço, desconecte o dispatcher2 do balanceador de carga.
6. Implante AEM pacotes para publish2 e o pacote do dispatcher para o dispatcher2 em paralelo, liberar o cache do dispatcher.
7. Coloque o dispatcher2 de volta no balanceador de carga.
   Esse processo continua até que a implantação tenha atingido todos os editores e dispatchers na topologia.

Modo de Execução do Pipeline de Emergência

Em situações críticas, os clientes do Adobe Managed Services podem precisar implantar alterações de código em seus ambientes de preparo e produção sem esperar que um ciclo de teste completo do Cloud Manager seja executado.

Para lidar com essas situações, o pipeline de produção do Cloud Manager pode ser executado em um emergência modo. Quando este modo é utilizado, as etapas dos testes de segurança e desempenho não são executadas; todas as outras etapas, incluindo qualquer etapa de aprovação configurada, são executadas como no modo de execução normal do pipeline.

Usando o Modo de Execução do Pipeline de Emergência

Ao iniciar a execução de um pipeline de produção, se esse recurso tiver sido ativado, é possível iniciar a execução no modo normal ou de emergência na caixa de diálogo, conforme mostrado na figura abaixo.

Além disso, ao visualizar a página de detalhes da execução do pipeline para uma execução em modo de emergência, a navegação estrutural na parte superior da tela mostra um indicador de que o modo de emergência foi usado para essa execução específica.

A criação de uma execução de pipeline nesse modo de emergência também pode ser feita por meio da API do Cloud Manager ou da CLI. Para iniciar uma execução no Modo de emergência, envie uma solicitação PUT para o endpoint de execução do pipeline com o parâmetro de consulta ?pipelineExecutionMode=EMERGENCY ou, ao usar a CLI:

$ aio cloudmanager:pipeline:create-execution PIPELINE_ID --emergency

Reexecutar uma implantação de produção

A reexecução da etapa de implantação de produção é compatível com execuções em que a etapa de implantação de produção foi concluída. O tipo de conclusão não é importante - a implantação pode ser bem-sucedida (somente para programas AMS), cancelada ou malsucedida. Dito isso, espera-se que o principal caso de uso seja os casos em que a etapa de implantação de produção falhou por motivos transitórios. A reexecução cria uma nova execução usando o mesmo pipeline. Essa nova execução consiste em três etapas:

1. A etapa de validação - é essencialmente a mesma validação que ocorre durante uma execução normal do pipeline.
2. A etapa de build - no contexto de uma reexecução, a etapa de build é a cópia de artefatos, não executando um novo processo de build.
3. A etapa de implantação de produção - usa a mesma configuração e as mesmas opções da etapa de implantação de produção em uma execução normal de pipeline.

A etapa de build pode ser rotulada de forma um pouco diferente na interface do usuário para refletir que está copiando artefatos, não reconstruindo.

Limitações:

• A reexecução da etapa de implantação de produção só estará disponível na última execução.
• A reexecução não está disponível para execuções de reversão.
• Se a última execução for uma execução de rollback, a reexecução não será possível.
• Se a última execução for uma execução de atualização por push, a reexecução não será possível.
• Se a última execução falhar em qualquer ponto antes da etapa de implantação de produção, a reexecução não será possível.

Reexecutar a API

Identificação de uma execução de nova execução

Para identificar se uma execução é uma execução reexecutada, o campo trigger pode ser examinado. Seu valor será RE_EXECUTE.

Acionamento de uma nova execução

Para acionar uma reexecução, uma solicitação de PUT precisa ser feita no HAL Link http://ns.adobe.com/adobecloud/rel/pipeline/reExecute no estado da etapa de implantação de produção. Se esse link estiver presente, a execução poderá ser reiniciada a partir dessa etapa. Se estiver ausente, a execução não poderá ser reiniciada dessa etapa. Na versão inicial, esse link só estará presente na etapa de implantação de produção, mas versões futuras poderão oferecer suporte para iniciar o pipeline a partir de outras etapas. Exemplo:

 {
  "_links": {
    "http://ns.adobe.com/adobecloud/rel/pipeline/logs": {
      "href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530/logs",
      "templated": false
    },
    "http://ns.adobe.com/adobecloud/rel/pipeline/reExecute": {
      "href": "/api/program/4/pipeline/1/execution?stepId=2983530",
      "templated": false
    },
    "http://ns.adobe.com/adobecloud/rel/pipeline/metrics": {
      "href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530/metrics",
      "templated": false
    },
    "self": {
      "href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530",
      "templated": false
    }
  },
  "id": "6187842",
  "stepId": "2983530",
  "phaseId": "1575676",
  "action": "deploy",
  "environment": "weretail-global-b75-prod",
  "environmentType": "prod",
  "environmentId": "59254",
  "startedAt": "2022-01-20T14:47:41.247+0000",
  "finishedAt": "2022-01-20T15:06:19.885+0000",
  "updatedAt": "2022-01-20T15:06:20.803+0000",
  "details": {
  },
  "status": "FINISHED"

A sintaxe do link HAL href O valor acima não se destina a ser usado como ponto de referência. O valor real deve sempre ser lido do link HAL e não gerado.

Envio de um PUT a solicitação para esse endpoint resultará em uma 201º se bem-sucedido e o corpo da resposta será a representação da nova execução. É semelhante a iniciar uma execução regular por meio da API.