Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Lorsque vous appelez Cloud Deploy pour créer une version à gérer par votre pipeline de livraison, le pipeline et les cibles sont conservés dans leur état actuel pour cette version. Vous pouvez toujours modifier votre pipeline de diffusion et vos fichiers de définition des cibles, mais les modifications que vous apportez n'affectent que les versions futures.
Pourquoi Cloud Deploy fait-il ceci ?
Pour que vos versions restent fiables et durables, le pipeline de livraison et les ressources associées sont conservés au moment de la création de la version. Cette conservation empêche les modifications récentes apportées à la définition du pipeline de livraison d'affecter la version de manières que les fichiers manifestes générés ne pourraient pas gérer.
Pourquoi est-ce important ?
Lorsqu'un pipeline de diffusion est modifié après la création de votre version, Cloud Deploy la diffuse conformément à la définition précédente du pipeline (telle qu'elle était lors de la création de la version), et non selon la nouvelle définition. Ce comportement n'est pas un problème, sauf si vous ou un autre membre de votre organisation attendez que la version suive le comportement du pipeline mis à jour.
Quand est-ce important ?
Lorsque vous promouvez un release
Lorsque la version a été créée pour la première fois, Cloud Deploy a pris un instantané du pipeline. Cet instantané (l'instance de pipeline) est la version du pipeline qui contrôle le cycle de déploiement de cet release.
Si quelqu'un modifie le pipeline, puis que vous promouvez la version vers la cible suivante, Cloud Deploy affiche un avertissement vous informant que le déploiement risque de ne pas se comporter comme prévu. Vous pouvez confirmer la promotion ou l'annuler.
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)?
Si vous confirmez que vous souhaitez continuer, la version est promue vers le cluster cible prévu, avec cette cible configurée comme définie lorsque vous avez créé le release. Autrement dit, les modifications apportées à la cible n'affectent pas cette release.
Lorsque vous approuvez une rollout
Comme pour la promotion, si vous approuvez un rollout et qu'il existe une incohérence entre l'instance de pipeline associée à la version et la définition actuelle du pipeline, Cloud Deploy affiche un message vous en informant. Vous pouvez confirmer ou annuler l'approbation.
Lorsque vous annulez un release.
Si un pipeline de diffusion ou une cible est modifié après un rollout et que vous essayez de le rétablir, il y aura un décalage de pipeline. Cloud Deploy vous invite à confirmer que vous souhaitez vraiment effectuer un rollback. Dans ce cas, nous vous recommandons vivement d'examiner la modification apportée au pipeline de diffusion ou à la cible avant de la rétablir.
Ce que vous pouvez faire
Si vous modifiez un pipeline de diffusion ou l'une de ses cibles après la création d'une version, vous pouvez procéder comme suit:
Laissez le pipeline d'origine continuer à s'exécuter, sans aucune modification apportée au pipeline modifié.
Les modifications apportées dans le pipeline n'affectent pas le reste de la version.
Créez une version.
La nouvelle version utilise le nouveau pipeline de diffusion modifié et redémarre avec la première cible de la progression de votre pipeline de diffusion.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/03 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/03 (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."]]
