Instâncias de pipeline por versão

Quando você invoca o Cloud Deploy para criar um novo lançamento a ser gerenciado pelo pipeline de entrega, o pipeline e os destinos são preservados no estado atual desse lançamento. Ainda é possível editar o pipeline de entrega e os arquivos de definição de destino, mas as alterações feitas afetam somente as versões futuras.

Por que o Cloud Deploy faz isso?

Para manter suas versões confiáveis e duráveis, o pipeline de entrega e os recursos associados a elas são preservados no momento em que a versão é criada. Essa preservação impede que alterações recentes na definição do pipeline de entrega afetem a versão de maneiras que os manifestos gerados talvez não consigam acomodar.

Por que isso é importante?

Quando um pipeline de entrega é alterado após a criação da versão, o Cloud Deploy entrega a versão de acordo com a definição anterior do pipeline (como era no momento da criação da versão), e não com a nova definição. Esse comportamento não é um problema, a menos que você ou outra pessoa na sua organização espere que a versão siga o comportamento atualizado do pipeline.

Quando é importante?

  • Quando você promove um release

    Quando a versão foi criada pela primeira vez, o Cloud Deploy tirou um snapshot do pipeline. Esse snapshot, a instância de pipeline, é a versão do pipeline que controla o ciclo de implantação dessa release.

    Se alguém editar o pipeline e você promover a versão para o próximo destino, o Cloud Deploy vai mostrar um aviso informando que a implantação pode não se comportar conforme o esperado. Você pode confirmar a promoção ou cancelá-la.

  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 você confirmar que quer continuar, a versão será promovida para o cluster de destino pretendido, com esse destino configurado conforme definido quando você criou o release. Ou seja, as mudanças no destino não afetam esse release.

  • Ao aprovar um rollout

    Assim como na promoção, se você aprovar um rollout e houver uma incompatibilidade entre a instância do pipeline associada à versão e a definição atual do pipeline, o Cloud Deploy vai mostrar uma mensagem informando incompatibilidade. Você pode confirmar ou cancelar a aprovação.

  • Ao reverter uma release.

    Se um pipeline ou uma meta de entrega for alterada após um rollout e você tentar reverter, haverá uma incompatibilidade de pipelines. O Cloud Deploy vai pedir que você confirme se realmente quer reverter. Nesse caso, recomendamos que você examine a alteração no pipeline ou no destino de entrega antes de fazer a reversão.

O que você pode fazer

Se você alterar um pipeline de entrega ou qualquer um dos destinos dele após a criação de uma versão, faça o seguinte:

  • Deixe o pipeline original continuar a execução, sem nenhuma das mudanças do pipeline editado.

    As mudanças no pipeline não afetam o restante da versão.

  • Crie um novo lançamento.

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