Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
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.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-21 UTC."],[[["\u003cp\u003eCloud Deploy preserves the delivery pipeline and target configurations at the time a release is created to ensure reliability and prevent unintended consequences from subsequent changes.\u003c/p\u003e\n"],["\u003cp\u003eChanges to the delivery pipeline or target definitions after a release is created will only affect future releases, not the existing one.\u003c/p\u003e\n"],["\u003cp\u003eWhen promoting, approving, or rolling back a release, Cloud Deploy checks for mismatches between the stored pipeline instance and the current pipeline definition, warning the user if discrepancies exist.\u003c/p\u003e\n"],["\u003cp\u003eIf there is a mismatch, the user will be prompted to confirm or cancel the action to either proceed or stop.\u003c/p\u003e\n"]]],[],null,["# Pipeline instances per release\n\nWhen you invoke Cloud Deploy to create a new release to be managed by your\ndelivery pipeline, the pipeline and targets are preserved in their current state\nfor that release. You can still edit your delivery pipeline and target\ndefinition files, but the changes that you make affect future releases only.\n| **Note:** In addition to storing the pipeline instance with the release, Cloud Deploy also stores the execution environment, as [defined with the target](/deploy/docs/config-files#target_definitions).\n\nWhy does Cloud Deploy do this?\n------------------------------\n\nTo keep your releases reliable and durable, the delivery pipeline and its\nassociated resources are preserved at the time the release is created. This\npreservation prevents recent changes to the delivery pipeline definition from\naffecting the release in ways the generated manifests might not be able to\naccommodate.\n\nWhy does this matter?\n---------------------\n\nWhen a delivery pipeline is changed after your release is created,\nCloud Deploy delivers the release according to the previous pipeline definition (as it was when the release was created) not the new definition. This\nbehavior isn't a problem unless you, or someone else in your organization,\nexpects the release to follow the updated pipeline behavior.\n\nWhen does this matter?\n----------------------\n\n- When you promote a `release`\n\n When the release was first created, Cloud Deploy took a snapshot\n of the pipeline. That snapshot---the *pipeline instance* ---is the\n version of the pipeline that controls the deployment cycle of that `release`.\n\n If anyone *does* edit the pipeline, and then you promote the release to the\n next target, Cloud Deploy displays a warning informing you that\n the deployment might not behave as you expect. You can respond by confirming\n the promotion or canceling it.\n\n```\n gcloud deploy releases promote \n ...\nThe pipeline or targets were cached when the release was created, but the source\nhas changed since then. You should review the differences before proceeding.\n\nPromoting release xxxx-release-00n to target xxx.\n\nDo you want to continue (Y/n)?\n\n```\n\nIf you confirm that you want to continue, then the release is promoted to\nthe intended target cluster, with that target configured as defined when you\ncreated the `release`. That is, changes to the target do not affect that\n`release`.\n\n- When you approve a `rollout`\n\n As with promotion, if you approve a `rollout` and there's a mismatch between\n the pipeline instance associated with the release, and the current pipeline\n definition, Cloud Deploy displays a message telling you about the\n mismatch. You can confirm or cancel the approval.\n- When you roll back a `release`.\n\n If a delivery pipeline or target is changed after a `rollout`, and you try to\n roll back, there will be a pipeline mismatch. Cloud Deploy will\n prompt you to confirm you really want to roll back. In this case, we strongly\n recommend you examine the change to the delivery pipeline or target before\n rolling back.\n\nWhat you can do\n---------------\n\nIf you change a delivery pipeline, or any of its targets, after a release is\ncreated, you can do the following:\n\n- Let the original pipeline continue executing, without any of the changes from\n the edited pipeline.\n\n The changes in the pipeline don't affect the rest of the release.\n- Create a new release.\n\n The new release uses the new, edited delivery pipeline, and starts again with\n the first target in your delivery pipeline progression."]]
