בדף הזה מוסבר איך לקדם גרסת Cloud Deploy קיימת ליעד הבא בהתקדמות של צינור העברת נתונים.
לפני שמתחילים
ההנחה היא שכבר יצרתם פריט תוכן.
קידום הגרסה
כשפריט התוכן להפצה נפרס ביעד שהוגדר בצינור ההפצה, אפשר לקדם אותו ליעד הבא:
gcloud
gcloud deploy releases promote --release=RELEASE_NAME \
--delivery-pipeline=PIPELINE_NAME \
--region=REGION
כאשר:
RELEASE_NAME הוא שם הגרסה שאתם מקדמים.
PIPELINE_NAME הוא השם של צינור העברת הנתונים שבו אתם משתמשים כדי לנהל את הפריסה של הגרסה הזו.
REGION הוא שם האזור שבו נוצרה הגרסה, למשל us-central1. זהו שדה חובה.
מידע נוסף על הפקודה gcloud deploy releases promote זמין בחומר העזר בנושא Google Cloud SDK.
המסוף
לוחצים על צינור עיבוד הנתונים שמופיע ברשימת צינורות עיבוד הנתונים להעברה.
בדף הפרטים של צינור ההפצה מוצג ייצוג גרפי של ההתקדמות בצינור ההפצה.

במסגרת ההדמיה של צינור העברת הנתונים, לוחצים על קידום ביעד הראשון.
מופיעה תיבת הדו-שיח קידום גרסה. בעמודה הזו מוצגים הפרטים של היעד שמקודם.
לוחצים על קידום.
אם צינור העברת הנתונים או היעד השתנו מאז יצירת הגרסה, Cloud Deploy מחזיר הודעה שמציינת אי התאמה אפשרית ומבקש לאשר את הקידום. אפשר להגיב n להנחיה ולבדוק את ההבדלים בין גרסאות הצינור לפני שממשיכים. אם בכל זאת בוחרים לקדם את הגרסה, היא נפרסת בהתאם לצינור ההפצה כפי שהוגדר כשהגרסה נוצרה. מידע נוסף על חוסר התאמה בין צינורות עיבוד נתונים זמין במאמר בנושא מופעים של צינורות עיבוד נתונים לכל גרסה.
Cloud Deploy יוצר rollout להפצה ביעד, וההפצה מתווספת לתור של הפריסה. כשפורסים את הצינור, ההדמיה של צינור ההפצה מראה את זה:

ניהול אישורים בצינור עיבוד נתונים לפריסה
אתם יכולים לדרוש אישור לכל יעד, ולאשר או לדחות פרסומים ביעד הזה.
אפשר לנהל אישורים באופן פרוגרמטי באמצעות שילוב של מערכת ניהול זרימות העבודה (כמו ServiceNow) או מערכת אחרת עם Cloud Deploy באמצעות Pub/Sub ו-Cloud Deploy API.
דרישת אישור
כדי שיידרש אישור לכל יעד, מגדירים את requireApproval לערך true בהגדרות היעד:
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name:
description:
requireApproval: true
פרטים נוספים זמינים במאמר בנושא הגדרת צינור העברת נתונים.
כשפריסה ממתינה לאישור, משתמשים או מערכות שרשומים לנושא clouddeploy-approvals Pub/Sub מקבלים התראה מהנושא clouddeploy-approvals, ואז יכולים לאשר או לדחות את הפריסה.
כשמשתמשים בפריסה מקבילה, אפשר להגדיר את היעד המרובה לדרושה אישור.
אם הקידום ליעד נדחה, ההשקה של בקר התנועה נכשלת, הסטטוס הוא APPROVAL_REJECTED, וההשקות של השותפים המשניים לא נוצרות.
אישור או דחייה של השקה
כל משתמש או חשבון שירות עם התפקיד roles/clouddeploy.approver יכולים לאשר פריסה של Cloud Deploy ליעד שנדרש אישור עבורו.
מערכת ניהול זרימות העבודה המשולבת שלכם, שקיבלה התראה על כך שנדרש אישור באמצעות התראות שירות, יכולה לאשר או לדחות את ההשקה באמצעות Cloud Deploy API.
אישור או דחייה ידניים
המסוף
במסוף Google Cloud , נכנסים לדף Delivery pipelines של Cloud Deploy כדי לראות רשימה של צינורות העברת הנתונים שזמינים לכם.
רשימת צינורות ההפצה מוצגת במסוף Google Cloud . צינורות העברת נתונים שהוגדרו אבל לא נרשמו בשירות Cloud Deploy לא מוצגים.
לוחצים על השם של צינור העברת הנתונים.
ההמחשה של צינור הנתונים מוצגת. אם האישור בהמתנה ויש לכם את התפקיד
roles/clouddeploy.approverאו הרשאות שוות ערך, ההדמיה כוללת את הקישור בדיקה.
לוחצים על בדיקה.
מוצגת רשימה של השקות שממתינות לאישור.

לוחצים על בדיקה.
מוצג המסך 'אישור השקת הגרסה'.

בכרטיסייה Manifest diff מוצגים שינויים במניפסט שעבר רינדור, מהגרסה שפרסתם כרגע (אם יש כזו) לגרסה שאתם מאשרים (או דוחים) עכשיו.
לוחצים על אישור או על דחייה.
אם תאשרו, האפליקציה שלכם תופעל ביעד. אם תדחו את הבקשה, האפליקציה לא תופעל ולא ניתן יהיה לאשר אותה בהמשך, אלא אם תועבר שוב לקידום.
gcloud
משתמש עם תפקיד roles/clouddeploy.approver יכול לאשר או לדחות פריסה באופן ידני. כדי לאשר:
gcloud deploy rollouts approve rollout-name --delivery-pipeline=pipeline-name \
--region=region \
--release=release-name
כדי לדחות:
gcloud deploy rollouts reject rollout-name --delivery-pipeline=pipeline-name \
--region=region \
--release=release-name