每個版本的管道執行個體

當您叫用 Cloud Deploy 建立要由推送管道管理的新版本時，管道和目標會保留該版本的目前狀態。您仍可編輯發布管線和目標定義檔案，但所做的變更只會影響日後的發布內容。

Cloud Deploy 為何要這麼做？

為確保發布版本可靠且持久，系統會在建立發布版本時保留發布管道和相關聯的資源。這樣可避免推送管道定義的近期變更，以生成資訊清單可能無法配合的方式影響發行內容。

為什麼這一點很重要？

如果發布後變更了發布管道，Cloud Deploy 會根據先前的管道定義 (也就是發布時的定義) 發布版本，而不是新的定義。除非您或貴機構的其他人希望版本遵循更新後的管道行為，否則這種行為不會造成問題。

這項異動何時生效？

  • 宣傳 release

    首次建立版本時，Cloud Deploy 會擷取管道的快照。這個快照 (即管道執行個體) 是管道版本，可控管該 release 的部署週期。

    如果有人確實編輯了管道，然後您將版本升級至下一個目標，Cloud Deploy 會顯示警告，告知您部署作業可能無法如預期運作。你可以確認或取消促銷活動來回應。

  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)?

如果確認要繼續，系統會將版本升級至預期目標叢集，並將該目標設定為您建立 release 時定義的目標。也就是說，目標變更不會影響該release。

  • 核准 rollout

    與升級相同，如果您核准 rollout，但與發布版本相關聯的管道執行個體與目前的管道定義不符，Cloud Deploy 會顯示訊息，告知您不符之處。你可以確認或取消核准。

  • 復原 release 時。

    如果在 rollout 後變更傳送管道或目標，並嘗試復原，管道就會不符。Cloud Deploy 會提示您確認是否真的要復原。在這種情況下，強烈建議您先檢查放送管道或目標的變更，再進行復原。

建議做法

如果發行內容建立後，您變更了放送管道或任何目標，可以採取下列做法：

  • 讓原始管道繼續執行，不採用編輯後管道的任何變更。

    管道中的變更不會影響發行內容的其他部分。

  • 建立新版本。

    新推出會使用經過編輯的新推送管道，並從推送管道進度中的第一個目標重新開始。