Organízate con las colecciones
Guarda y clasifica el contenido según tus preferencias.
Cuando invocas Cloud Deploy para crear una versión que gestione tu flujo de procesamiento de entrega, la canalización y los destinos se conservan en su estado actual para esa versión. Puedes seguir editando tu canal de distribución y tus archivos de definición de destino, pero los cambios que hagas solo afectarán a las versiones futuras.
¿Por qué hace esto Cloud Deploy?
Para que tus lanzamientos sean fiables y duraderos, el flujo de procesamiento de entrega y sus recursos asociados se conservan en el momento en que se crea el lanzamiento. De esta forma, se evita que los cambios recientes en la definición de la canalización de entrega afecten al lanzamiento de formas que los manifiestos generados no puedan admitir.
¿Por qué es importante?
Si se cambia una canalización de entrega después de crear una versión, Cloud Deploy entrega la versión según la definición de la canalización anterior (tal como estaba cuando se creó la versión), no según la nueva definición. Este comportamiento no supone un problema a menos que tú u otra persona de tu organización esperéis que la versión siga el comportamiento actualizado de la canalización.
¿Cuándo es importante?
Cuando promocionas un release
Cuando se creó la versión por primera vez, Cloud Deploy hizo una instantánea de la canalización. Esa instantánea, la instancia de la canalización, es la versión de la canalización que controla el ciclo de implementación de ese release.
Si alguien edita la canalización y, a continuación, asciendes la versión a la siguiente de destino, Cloud Deploy muestra una advertencia para informarte de que es posible que la implementación no se comporte como esperas. Puedes responder confirmando la promoción o cancelándola.
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 confirma que quiere continuar, la versión se promocionará al clúster de destino previsto, con ese destino configurado tal como se definió al crear el release. Es decir, los cambios en el objetivo no afectan a ese release.
Cuando apruebas un rollout
Al igual que con las promociones, si apruebas un rollout y hay una discrepancia entre la instancia de la canalización asociada al lanzamiento y la definición de la canalización actual, Cloud Deploy muestra un mensaje que te informa de la discrepancia. Puedes confirmar o cancelar la aprobación.
Cuando reviertes una release.
Si se cambia una canalización o un destino de entrega después de un rollout y se intenta restaurar una versión anterior, habrá un error de coincidencia en la canalización. Cloud Deploy te pedirá que confirmes que quieres restaurar la versión anterior. En este caso, te recomendamos que examines el cambio en la canalización de entrega o en el destino antes de revertir el cambio.
Qué puedes hacer
Si cambias una canalización de distribución o cualquiera de sus destinos después de crear una versión, puedes hacer lo siguiente:
Dejar que la canalización original siga ejecutándose sin ninguno de los cambios de la canalización editada.
Los cambios en la canalización no afectan al resto de la versión.
Crea una versión.
La nueva versión usa la nueva canalización de entrega editada y vuelve a empezar con el primer objetivo de la progresión de la canalización de entrega.
[[["Es fácil de entender","easyToUnderstand","thumb-up"],["Me ofreció una solución al problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Es difícil de entender","hardToUnderstand","thumb-down"],["La información o el código de muestra no son correctos","incorrectInformationOrSampleCode","thumb-down"],["Me faltan las muestras o la información que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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."]]
