Instâncias de pipeline por lançamento

Quando invoca o Cloud Deploy para criar um novo lançamento a ser gerido pelo seu pipeline de implementação, o pipeline e os destinos são preservados no respetivo estado atual para esse lançamento. Pode continuar a editar os ficheiros de definição de destino e pipeline de entrega, mas as alterações que fizer afetam apenas os lançamentos futuros.

Por que motivo o Cloud Deploy faz isto?

Para manter os lançamentos fiáveis e duradouros, o pipeline de entrega e os respetivos recursos são preservados no momento em que o lançamento é criado. Esta preservação impede que as alterações recentes à definição do pipeline de fornecimento afetem o lançamento de formas que os manifestos gerados possam não conseguir acomodar.

Porque é que isto é importante?

Quando um pipeline de implementação é alterado após a criação do lançamento, o Cloud Deploy implementa o lançamento de acordo com a definição do pipeline anterior (tal como estava quando o lançamento foi criado) e não com a nova definição. Este comportamento não é um problema, a menos que o utilizador ou outra pessoa na sua organização espere que o lançamento siga o comportamento atualizado do pipeline.

Quando é que isto é importante?

  • Quando promove um release

    Quando o lançamento foi criado pela primeira vez, o Cloud Deploy tirou uma captura de ecrã do pipeline. Essa imagem instantânea, a instância do pipeline, é a versão do pipeline que controla o ciclo de implementação desse release.

    Se alguém editar o pipeline e, em seguida, promover a versão para o destino seguinte, o Cloud Deploy apresenta um aviso a informar que a implementação pode não funcionar como esperado. Pode responder confirmando a promoção ou cancelando-a.

  gcloud deploy releases promote 
      …
The pipeline or targets were cached when the release was created, but the source
has changed since then. You should review the differences before proceeding.

Promoting release xxxx-release-00n to target xxx.

Do you want to continue (Y/n)?

Se confirmar que quer continuar, o lançamento é promovido para o cluster de destino pretendido, com esse destino configurado conforme definido quando criou o release. Ou seja, as alterações ao alvo não afetam esse release.

  • Quando aprova uma rollout

    Tal como acontece com a promoção, se aprovar um rollout e existir uma incompatibilidade entre a instância do pipeline associada ao lançamento e a definição do pipeline atual, o Cloud Deploy apresenta uma mensagem a informar sobre a incompatibilidade. Pode confirmar ou cancelar a aprovação.

  • Quando reverte uma release.

    Se uma conduta de entrega ou um alvo for alterado após rollout e tentar reverter, vai ocorrer uma incompatibilidade de condutas. O Cloud Deploy pede-lhe que confirme se quer mesmo reverter. Neste caso, recomendamos vivamente que examine a alteração à conduta de fornecimento ou ao alvo antes de reverter.

O que pode fazer

Se alterar um pipeline de fornecimento ou qualquer um dos respetivos destinos após a criação de um lançamento, pode fazer o seguinte:

  • Permitir que o pipeline original continue a ser executado sem nenhuma das alterações do pipeline editado.

    As alterações no pipeline não afetam o resto do lançamento.

  • Crie um novo lançamento.

    O novo lançamento usa o novo pipeline de publicação editado e começa novamente com o primeiro alvo na progressão do pipeline de publicação.