Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Wenn Sie Cloud Deploy aufrufen, um einen neuen Release zu erstellen, der von Ihrer Bereitstellungspipeline verwaltet werden soll, werden die Pipeline und die Ziele in ihrem aktuellen Status für diesen Release beibehalten. Sie können die Bereitstellungspipeline und die Zieldefinitionsdateien weiterhin bearbeiten, die von Ihnen vorgenommenen Änderungen wirken sich jedoch nur auf zukünftige Versionen aus.
Warum macht Cloud Deploy das?
Damit die Releases zuverlässig und langlebig sind, werden die Delivery-Pipeline und die zugehörigen Ressourcen zum Zeitpunkt der Release-Erstellung beibehalten. Diese Beibehaltung verhindert, dass kürzlich vorgenommene Änderungen an der Bereitstellungspipelinedefinition den Release auf eine Weise beeinflussen, die von den generierten Manifesten möglicherweise nicht übernommen werden kann.
Warum ist das Problem überhaupt bedeutsam?
Wenn eine Bereitstellungspipeline nach dem Erstellen Ihres Release geändert wird, stellt Cloud Deploy den Release gemäß der vorherigen Pipelinedefinition (zum Zeitpunkt der Erstellung des Release) und nicht nach der neuen Definition bereit. Dieses Verhalten ist nur dann ein Problem, wenn Sie oder jemand anderes in Ihrer Organisation davon ausgeht, dass der Release dem aktualisierten Pipelineverhalten folgt.
Wann ist das wichtig?
Wenn Sie einen release hochstufen
Beim ersten Erstellen des Release hat Cloud Deploy einen Snapshot der Pipeline erstellt. Dieser Snapshot – die Pipeline-Instanz – ist die Version der Pipeline, die den Deployment-Zyklus dieses release steuert.
Wenn jemand die Pipeline bearbeitet und Sie dann den Release zum nächsten Ziel hochstufen, zeigt Cloud Deploy eine Warnung an, dass die Bereitstellung möglicherweise nicht wie erwartet funktioniert. Sie können reagieren, indem Sie die Hochstufung bestätigen oder sie abbrechen.
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)?
Wenn Sie bestätigen, dass Sie fortfahren möchten, wird die Version zum gewünschten Zielcluster hochgestuft, wobei dieses Ziel beim Erstellen der release definiert wurde. Das heißt, Änderungen am Ziel wirken sich nicht auf release aus.
Wenn Sie eine rollout genehmigen
Wie bei der Hochstufung zeigt Cloud Deploy eine Meldung darüber an, ob die rollout-Pipeline mit dem Release und die aktuelle Pipelinedefinition nicht übereinstimmt. Sie können die Genehmigung bestätigen oder abbrechen.
Wenn Sie ein release zurücksetzen.
Wenn eine Bereitstellungspipeline oder ein Ziel nach einem rollout geändert wird und Sie ein Rollback durchführen, kommt es zu einer Pipelineabweichung. Cloud Deploy fordert Sie auf, zu bestätigen, dass Sie ein Rollback durchführen möchten. In diesem Fall empfehlen wir Ihnen dringend, die Änderung an der Bereitstellungspipeline oder dem Ziel zu prüfen, bevor Sie ein Rollback durchführen.
Das können Sie tun
Wenn Sie eine Bereitstellungspipeline oder eines ihrer Ziele nach dem Erstellen eines Release ändern, haben Sie folgende Möglichkeiten:
Die Ausführung der ursprünglichen Pipeline wird fortgesetzt, ohne dass die Änderungen aus der bearbeiteten Pipeline berücksichtigt werden.
Die Änderungen in der Pipeline wirken sich nicht auf den Rest der Version aus.
Erstellen Sie einen neuen Release.
Der neue Release verwendet die neue, bearbeitete Bereitstellungspipeline und beginnt wieder mit dem ersten Ziel in der Bereitstellungspipeline.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-17 (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."]]
