Comportamento padrão (sem reimplantação forçada)

Quando não force-redeploy está definido ou está definido como false, o pipeline é implantado apenas quando novas alterações são detectadas no repositório de inventário do ambiente de destino.

1. O pipeline do CD é iniciado e marca o commit atual com o ID de execução do pipeline.

2. O pipeline lê o conteúdo do ramo do ambiente correspondente a partir dessa tag.

3. O pipeline calcula o delta de implementação entre o commit atual e o commit associado à tag <target-environment>_latest.

4. O pipeline avalia o delta:

   • Se o delta estiver vazio, o pipeline será interrompido e nenhuma implantação ocorrerá.
   • Se o delta contiver alterações, o pipeline continua.

5. O pipeline implementa as alterações identificadas no delta.

6. Após uma implantação bem-sucedida, o pipeline anexa a <target-environment>_latest tag ao novo commit.

Comportamento forçado (com reimplantação forçada)

Quando force-redeploy está definido como true, o pipeline ignora a validação delta e reimplemente o inventário completo, independentemente das alterações detectadas. Essa abordagem garante que o estado completo do aplicativo seja reaplicado ao destino da implantação.

1. O pipeline do CD é iniciado e marca o commit atual com o ID de execução do pipeline.
2. O pipeline lê o conteúdo do ramo do ambiente correspondente a partir dessa tag.
3. O pipeline calcula o delta de implantação, que normalmente está vazio neste cenário.
4. A force-redeploy=true configuração faz com que o pipeline ignore a verificação delta e prossiga.
5. O pipeline reimplemente todo o estado do aplicativo a partir do branch.
6. Após uma reimplantação bem-sucedida, o pipeline anexa a <target-environment>_latest tag ao commit que acabou de implantar.

Visão geral do pipeline de reversão

Esse pipeline permite que você reverta para uma configuração anterior conhecida como válida, direcionando uma ID de solicitação de ServiceNow alteração específica (por exemplo, CHG-12345).

Este ID de solicitação de alteração serve como um marcador exclusivo para uma implantação bem-sucedida e é uma entrada obrigatória para o pipeline de reversão.

Você pode encontrar o ID da solicitação de alteração para uma implantação anterior de duas maneiras:

• ServiceNow: Localize a solicitação de mudança para a implementação que você deseja restaurar.
• Repositório de inventário: como o estado do inventário é gerenciado no controle de origem, cada implantação é identificada de forma exclusiva por um commit. Você pode encontrar o commit que deseja reverter e identificar a CHG-*** tag associada a esse commit.

O pipeline de reversão contém as seguintes etapas:

• prod-rollback-start
• prod-setup
• prod-rollback-change-request
• prod-deployment
• prod-acceptance-tests
• prod-rollback-finish

A execução do pipeline usa informações da propriedade rollback-change-request-id environment para criar uma nova solicitação de alteração.

Para manter a conformidade, o pipeline reabre questões relacionadas à implantação anterior. Essas questões estão anexadas à nova solicitação de alteração, e suas datas de vencimento originais permanecem inalteradas. Uma reversão bem-sucedida move a _latest tag no inventário para o commit anterior.

Criar um pipeline de reversão

Use o cd-rollback-listener para acionar uma reversão para a última versão válida conhecida.

1. Vá para o seu pipeline de CD.
2. Adicione um acionador manual ou duplique o Acionador Manual de CD.
3. Edite o gatilho e defina o ouvinte como cd-rollback-listener.
4. Selecione Salvar.
5. Crie um gatilho separado para cada combinação necessária de região e ambiente de destino.

Acionar um pipeline de reversão

Uma execução do pipeline de reversão usa as seguintes propriedades de ambiente:

O pipeline é encerrado, a menos que os seguintes critérios sejam atendidos:

• rollback-change-request-id deve ser o ID de uma implantação concluída para a mesma região e ambiente de destino.
• A implantação associada a não rollback-change-request-id deve ser mais antiga do que o número de implantações especificado por rollback-limit.

A propriedade PIPELINE_NAME do ambiente Tekton determina se uma execução é uma implantação ou uma reversão.

• cd-rollback-pipeline: Valor padrão para uma reversão.
• cd-pipeline: Valor padrão para uma implantação.

Você pode usar essa propriedade para personalizar a lógica de ramificação.

Visão geral da reversão usando GitOps

Use o pipeline de implantação contínua para implantar uma versão anterior do inventário no ambiente de destino usando Git operações que revertem as alterações para um específico commit-id.

Como você está revertendo commits diretamente no repositório de inventário, em vez de acionar o pipeline de reversão com um ID de ServiceNow solicitação de alteração, esse processo não reabre automaticamente as questões de conformidade anteriores nem gerencia suas datas de vencimento.

Quando acionado, o pipeline de CD conclui as seguintes etapas para a reimplantação:

• O pipeline é iniciado e marca o commit atual (o commit de reversão) com o ID de execução do pipeline.
• O pipeline lê o conteúdo do ramo do ambiente correspondente a partir dessa tag.
• O pipeline calcula o delta de implementação entre o commit atual e o commit associado à tag <target-environment>_latest.
• Após uma implantação bem-sucedida, a <target-environment>_latest tag é movida para o novo commit (revertido).

Criar uma solicitação pull para promoção de reversão

1. Identifique a versão commit-id da implantação no inventário para a qual você deseja reverter.
2. Reverta o estado do repositório para esse commit.
3. Crie uma solicitação pull para promover o estado revertido.

O exemplo a seguir mostra esse cenário usando git comandos.

1. Liste commits e tags para encontrar o ID do commit do último estado válido conhecido (por exemplo, refs/tags/8)

   # /c/usr/devsecops/compliance-inventory (master)
   $ git show-ref --tags
   ...
   83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8 refs/tags/8
   ...
   1914a125e76aa97c497f4bd2c2f455b58cf079b8 refs/tags/prod_latest
   

2. Liste todos os commits entre o estado atual (refs/tags/prod_latest) e o estado alvo (refs/tags/8).

   # /c/usr/devsecops/compliance-inventory (master)
   $ git rev-list --no-merges HEAD...83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8
   67cc8babdff3e09c1f0e632f897798c1b5424f38
   6fab5ce3d60590cd858206424ecfd7d3a8c9ceb4
   ...
   

3. Reverter o estado do inventário para o commit de destino (refs/tags/8).

   # /c/usr/devsecops/compliance-inventory (master)
   $ git revert -n $(git rev-list --no-merges HEAD...83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8)
   

4. Confirme o novo estado.

   # /c/usr/devsecops/compliance-inventory (master|REVERTING)
   $ git commit -m "revert master to 83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8"
   [master af82538] revert master to 83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8
   

5. Envie a atualização para o branch master.

   # /c/usr/devsecops/compliance-inventory (master)
   $ git push --set-upstream origin master
   ...
   To [https://us-south.git.cloud.ibm.com/jaunin.b/compliance-inventory.git](https://us-south.git.cloud.ibm.com/jaunin.b/compliance-inventory.git)
     67cc8ba..af82538  master -> master
   ...
   

Acionar o pipeline de implantação contínua

1. Crie uma solicitação pull para as alterações de promoção de reversão.

2. Revisar e mesclar o pull request.

3. Acionar a execução manual do pipeline de CD em sua cadeia de ferramentas de CD.

Visão geral do Rollback em linha

Este modo reverte a implantação atual dentro do contexto da mesma execução do pipeline. É necessário quando ocorre um erro ou falha durante a fase de implantação ou teste de aceitação, fazendo com que a tentativa de implantação seja marcada como falha.

Uma reversão em linha é executada automaticamente se a propriedade rollback-enabled do ambiente estiver definida como 1 e ocorrer uma falha na fase de teste de implantação ou aceitação.

Se uma reversão for acionada, o pipeline de CD executa o segmento definido para rollback em seu .pipeline-config.yaml arquivo. Se um rollback segmento não estiver definido no arquivo, uma implementação padrão será executada e solicitará que você forneça um script de reversão.

Exemplo de script de reversão em .pipeline-config.yaml:

rollback:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.74
  script: |
    #!/usr/bin/env bash
    if [[ "$PIPELINE_DEBUG" == 1 ]]; then
      trap env EXIT
      env
      set -x
    fi
    source $WORKSPACE/$PIPELINE_CONFIG_REPO_PATH/scripts/deploy_setup.sh
    source $WORKSPACE/$PIPELINE_CONFIG_REPO_PATH/scripts/rollback.sh

Propriedades definidas durante a reversão inline

• rollback-status: Indica o status da etapa de reversão. Valores possíveis: [notRun, success, failure]
• rollback-exit-code: O código de saída da etapa de reversão. Este valor fica vazio se a reversão não tiver sido executada.
• default-rollback-executed: Defina como true se a implementação padrão (que solicita um script) foi executada. Esse valor está vazio por padrão.
• pipeline-execution-status: Indica o status da execução geral do pipeline. Valores possíveis: [successful_deployment, failed_deployment_failed_rollback, failed_deployment_successful_rollback]