Instances de pipeline par version

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.