פיתוח רציף (continuous delivery) בסגנון GitOps באמצעות Cloud Built

בדף הזה מוסבר איך ליצור צינור עיבוד נתונים לאינטגרציה רציפה ופיתוח רציף (CI/CD) ב- Google Cloud באמצעות מוצרים מתארחים בלבד והשיטה הפופולרית GitOps.

מהנדסי Google מאחסנים קובצי הגדרה ופריסה במאגר קודי המקור הראשי שלנו כבר הרבה זמן. המתודולוגיה הזו מתוארת בספר Site Reliability Engineering, Chapter 8 (Beyer et. al., ‫2016), והוצג על ידי קלסי הייטאואר במהלך הנאום המרכזי שלו ב-Google Cloud Next '17.

חלק מרכזי ב-GitOps הוא הרעיון של 'סביבות כקוד': תיאור הפריסות באופן הצהרתי באמצעות קבצים (לדוגמה, מניפסטים של Kubernetes) שמאוחסנים במאגר Git.

במדריך הזה יוצרים פייפליין של CI/CD שבו מתבצעות הפעולות הבאות באופן אוטומטי: בניית קובץ אימג' של קונטיינר מקוד שנשמר, אחסון התמונה ב-Artifact Registry, עדכון מניפסט של Kubernetes במאגר Git ופריסת האפליקציה ב-Google Kubernetes Engine‏ (GKE) באמצעות המניפסט הזה.

ארכיטקטורה של צינור עיבוד נתונים של CI/CD

במדריך הזה נשתמש בשני מאגרי Git:

מאגר האפליקציות: מכיל את קוד המקור של האפליקציה עצמה
‫env repository: מכיל את המניפסטים של פריסת Kubernetes

כשמעבירים בדחיפה שינוי למאגר האפליקציה, צינור הנתונים של Cloud Build מריץ בדיקות, יוצר קובץ אימג' של קונטיינר ומעביר אותו בדחיפה ל-Artifact Registry. אחרי שמעבירים את קובץ האימג' בדחיפה, Cloud Build מעדכן את מניפסט הפריסה ומעביר אותו בדחיפה למאגר env. הפעולה הזו מפעילה צינור עיבוד נתונים נוסף של Cloud Build שמחיל את המניפסט על אשכול GKE, ואם הפעולה מצליחה, מאחסן את המניפסט בענף אחר של מאגר env.

אנחנו שומרים את מאגרי app ו-env בנפרד כי יש להם מחזורי חיים ושימושים שונים. המשתמשים העיקריים במאגר האפליקציה הם בני אדם, והמאגר הזה מוקדש לאפליקציה ספציפית. המשתמשים העיקריים במאגר env הם מערכות אוטומטיות (כמו Cloud Build), ויכול להיות שמאגר זה משותף לכמה אפליקציות. מאגר env יכול לכלול כמה ענפים, שכל אחד מהם ממופה לסביבה ספציפית (במדריך הזה משתמשים רק בסביבת הייצור) ומפנה לקובץ אימג' של קונטיינר ספציפי, בעוד שמאגר app לא יכול לכלול כמה ענפים.

בסיום המדריך הזה, יהיה לכם מערכת שבה תוכלו בקלות:

כדי להבחין בין פריסות שנכשלו לבין פריסות שהצליחו, אפשר לעיין בהיסטוריה של Cloud Build.
כדי לגשת למניפסט שבו נעשה שימוש כרגע, צריך לעיין בענף production במאגר env,
אפשר לחזור לכל גרסה קודמת על ידי הפעלה מחדש של גרסת ה-build המתאימה ב-Cloud Build.

זרימת צינור עיבוד הנתונים של CI/CD

מידע על המדריך הזה

במדריך הזה נעשה שימוש ב-Cloud Source Repositories לאירוח מאגרי Git, אבל אפשר להשיג את אותן תוצאות גם באמצעות מוצרי צד שלישי אחרים כמו GitHub,‏ Bitbucket או GitLab.

בצינור הזה לא מיושם מנגנון אימות לפני הפריסה. אם אתם משתמשים ב-GitHub, ב-Bitbucket או ב-GitLab, אתם יכולים לשנות את הצינור כדי להשתמש בבקשת משיכה למטרה הזו.

אנחנו ממליצים על Spinnaker לצוותים שרוצים להטמיע דפוסי פריסה מתקדמים (כחול/ירוק, ניתוח קנרי, ריבוי עננים וכו'), אבל יכול להיות שקבוצת התכונות שלו לא נחוצה לארגונים קטנים ולפרויקטים קטנים כדי להצליח באסטרטגיית CI/CD. במדריך הזה מוסבר איך ליצור צינור עיבוד נתונים של CI/CD שמתאים לאפליקציות שמארחים ב-GKE באמצעות כלי פיתוח.

כדי לפשט את המדריך, השתמשנו בסביבה אחת – production – במאגר env, אבל אפשר להרחיב את ההגדרה כך שתתבצע פריסה למספר סביבות אם יש צורך בכך.

מטרות

יוצרים מאגרי Git ב-Cloud Source Repositories.
יוצרים קובץ אימג' של קונטיינר באמצעות Cloud Build ומאחסנים אותו ב-Artifact Registry.
יוצרים צינור CI.
ליצור צינור עיבוד נתונים של CD.
בודקים את צינור עיבוד הנתונים של CI/CD.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

כדי ליצור הערכת עלויות בהתאם לשימוש החזוי, אפשר להשתמש במחשבון התמחור.

יכול להיות שמשתמשים חדשים ב- Google Cloud זכאים לתקופת ניסיון בחינם.

כשמסיימים את המשימות שמתוארות במסמך הזה אפשר למחוק את המשאבים שיצרתם כדי להימנע מחיובים נוספים. מידע נוסף זמין בקטע הסרת המשאבים.

לפני שמתחילים

בוחרים או יוצרים Google Cloud פרויקט.

מעבר לניהול משאבים
מפעילים את החיוב בפרויקט.

הפעלת החיוב
פותחים את Cloud Shell כדי להריץ את הפקודות שמפורטות במדריך הזה. ‫Cloud Shell היא סביבת מעטפת אינטראקטיבית של Google Cloud שמאפשרת לכם לנהל את הפרויקטים והמשאבים שלכם מדפדפן האינטרנט.

כניסה ל-Cloud Shell
אם הפקודה gcloud config get-value project לא מחזירה את המזהה של הפרויקט שבחרתם, צריך להגדיר את Cloud Shell לשימוש בפרויקט.
```
gcloud config set project [PROJECT_ID]
```

ב-Cloud Shell, מפעילים את ממשקי ה-API הנדרשים.

gcloud services enable container.googleapis.com \
    cloudbuild.googleapis.com \
    sourcerepo.googleapis.com \
    artifactregistry.googleapis.com

יוצרים מאגר Docker ב-Artifact Registry בשם my-repository באזור us-central1 כדי לאחסן את קובצי האימג' של הקונטיינרים.
```
gcloud artifacts repositories create my-repository \
  --repository-format=docker \
  --location=us-central1
```
ב-Cloud Shell, יוצרים אשכול GKE שבו ישתמשו כדי לפרוס את האפליקציה לדוגמה של המדריך הזה.
טייס אוטומטי
יוצרים אשכול Autopilot בשם hello-cloudbuild:
```
gcloud container clusters create-auto hello-cloudbuild \
    --location us-central1
```
רגילה
יוצרים אשכול רגיל עם צומת אחד בשם hello-cloudbuild:
```
gcloud container clusters create hello-cloudbuild \
    --num-nodes 1 --location us-central1
```
אם עדיין לא השתמשתם ב-Git ב-Cloud Shell, תצטרכו להגדיר את Git עם השם וכתובת האימייל שלכם. ‫Git ישתמש בפרטים האלה כדי לזהות אתכם כיוצרי הקומיטים שתצרו ב-Cloud Shell.
```
git config --global user.email "YOUR_EMAIL_ADDRESS"
git config --global user.name "YOUR_NAME"
```

כדי להימנע מחיובים נוספים אחרי שסיימתם את המדריך, תוכלו למחוק את המשאבים שיצרתם. פרטים נוספים מופיעים במאמר בנושא הסרת המשאבים.

יצירת מאגרי Git ב-Cloud Source Repositories

בקטע הזה יוצרים את שני מאגרי ה-Git‏ (app ו-env) שבהם נעשה שימוש במדריך הזה, ומפעילים את מאגר app עם קוד לדוגמה.

יוצרים את שני מאגרי ה-Git ב-Cloud Shell.

gcloud source repos create hello-cloudbuild-app
gcloud source repos create hello-cloudbuild-env

משכפלים את הקוד לדוגמה מ-GitHub.

cd ~
git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
cd ~/kubernetes-engine-samples/management/gitops-style-delivery/

הגדרת Cloud Source Repositories כמיקום מרוחק.

PROJECT_ID=$(gcloud config get-value project)
git remote add google \
    "https://source.developers.google.com/p/${PROJECT_ID}/r/hello-cloudbuild-app"

הקוד ששיבטתם מכיל אפליקציית Hello World.

from flask import Flask
app = Flask('hello-cloudbuild')

@app.route('/')
def hello():
  return "Hello World!\n"

if __name__ == '__main__':
  app.run(host = '0.0.0.0', port = 8080)

יצירת קובץ אימג' של קונטיינר באמצעות Cloud Build

הקוד ששיבטתם מכיל את קובץ ה-Dockerfile הבא.

FROM python:3.13-slim
RUN pip install flask
WORKDIR /app
COPY app.py /app/app.py
ENTRYPOINT ["python"]
CMD ["/app/app.py"]

בעזרת קובץ Dockerfile הזה, אפשר ליצור קובץ אימג' של קונטיינר באמצעות Cloud Build ולאחסן אותו ב-Artifact Registry.

ב-Cloud Shell, יוצרים גרסת build של Cloud Build על סמך הקומיט האחרון באמצעות הפקודה הבאה.
```
cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
COMMIT_ID="$(git rev-parse --short=7 HEAD)"
gcloud builds submit --tag="us-central1-docker.pkg.dev/${PROJECT_ID}/my-repository/hello-cloudbuild:${COMMIT_ID}" .
```
כשמריצים את הפקודה הזו, Cloud Build מעביר בסטרימינג את היומנים שנוצרו במהלך יצירת קובץ האימג' של הקונטיינר למסוף.
אחרי שגרסת ה-build מסתיימת, מוודאים שקובץ אימג' הקונטיינר החדש זמין ב-Artifact Registry.

מעבר אל Artifact Registry

יצירת פייפליין של אינטגרציה רציפה

בקטע הזה מגדירים את Cloud Build כך שיריץ באופן אוטומטי בדיקת יחידה קטנה, ייצור את קובץ האימג' של הקונטיינר ואז יעביר אותו בדחיפה ל-Artifact Registry. העלאה של קומיט חדש ל-Cloud Source Repositories מפעילה אוטומטית את צינור העברת הנתונים הזה. קובץ cloudbuild.yaml שכלול בקוד הוא ההגדרה של צינור עיבוד הנתונים.

steps:
# This step runs the unit tests on the app
- name: 'python:3.13-slim'
  id: Test
  entrypoint: /bin/sh
  args:
  - -c
  - 'pip install flask && python test_app.py -v'

# This step builds the container image.
- name: 'gcr.io/cloud-builders/docker'
  id: Build
  args:
  - 'build'
  - '-t'
  - 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:$SHORT_SHA'
  - '.'

# This step pushes the image to Artifact Registry
# The PROJECT_ID and SHORT_SHA variables are automatically
# replaced by Cloud Build.
- name: 'gcr.io/cloud-builders/docker'
  id: Push
  args:
  - 'push'
  - 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:$SHORT_SHA'

פותחים את הדף Triggers (טריגרים) של Cloud Build.

כניסה לדף Triggers
לוחצים על Create trigger (יצירת ביטוי להפעלה).
ממלאים את האפשרויות הבאות:
- בשדה שם, מקלידים hello-cloudbuild.
- בקטע Event, בוחרים באפשרות Push to a branch.
- בקטע Source, בוחרים באפשרות hello-cloudbuild-app בתור Repository ובאפשרות ^master$ בתור Branch.
- בקטע תצורת build, בוחרים באפשרות קובץ תצורה של Cloud Build.
- בשדה מיקום קובץ התצורה של Cloud Build, מקלידים cloudbuild.yaml אחרי /.
לוחצים על יצירה כדי לשמור את טריגר לפיתוח גרסת Build.

טיפ: אם אתם צריכים ליצור טריגרים לבנייה עבור הרבה פרויקטים, אתם יכולים להשתמש ב-Build Triggers API.
ב-Cloud Shell, מעבירים בדחיפה את קוד האפליקציה אל Cloud Source Repositories כדי להפעיל את צינור ה-CI ב-Cloud Build.
```
cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
git push google master
```
פותחים את מסוף Cloud Build.

כניסה ל-Cloud Build

יופיעו הבנייה שהופעלה לאחרונה והבנייה שהסתיימה. אפשר ללחוץ על build כדי לעקוב אחרי ההרצה שלו ולבדוק את היומנים שלו.

יצירת צינור עיבוד הנתונים לפיתוח רציף

משתמשים ב-Cloud Build גם לצינור העיבוד של פיתוח רציף (CD). הצינור מופעל בכל פעם ששולחים commit לענף candidate במאגר hello-cloudbuild-env. הצינור מחיל את הגרסה החדשה של המניפסט על אשכול Kubernetes, ואם הפעולה מצליחה, הוא מעתיק את המניפסט אל הענף production. לתהליך הזה יש את המאפיינים הבאים:

הסתעפות candidate היא היסטוריה של ניסיונות הפריסה.
הסתעפות הייצור היא היסטוריה של הפריסות שבוצעו בהצלחה.
אתם יכולים לראות את הפריסות שבוצעו בהצלחה ואת הפריסות שנכשלו ב-Cloud Build.
אפשר לחזור לכל פריסה קודמת על ידי הפעלה מחדש של ה-build המתאים ב-Cloud Build. בנוסף, ביטול השינוי מעדכן את הענף production כך שישקף באופן מדויק את היסטוריית הפריסות.

תשנו את צינור עיבוד הנתונים של האינטגרציה הרציפה כדי לעדכן את הסתעפות המועמד של מאגר hello-cloudbuild-env, וכך תפעילו את צינור עיבוד הנתונים של הפיתוח הרציף.

מתן גישה ל-GKE מ-Cloud Build

כדי לפרוס את האפליקציה באשכול Kubernetes, ל-Cloud Build צריך להיות תפקיד ניהול זהויות והרשאות גישה של מפתח Kubernetes Engine.

מעטפת

ב-Cloud Shell, מריצים את הפקודה הבאה:

PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} --format='get(projectNumber)')"
gcloud projects add-iam-policy-binding ${PROJECT_NUMBER} \
    --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
    --role=roles/container.developer

המסוף

במסוף Google Cloud , עוברים לדף GKE Permissions:
עוברים אל הרשאות
מגדירים את הסטטוס של התפקיד מפתח Kubernetes Engine להפעלה.

אתחול המאגר hello-cloudbuild-env

צריך לאתחל את מאגר hello-cloudbuild-env עם שני ענפים (production ו-candidate) וקובץ תצורה של Cloud Build שמתאר את תהליך הפריסה.

ב-Cloud Shell, משכפלים את המאגר hello-cloudbuild-env ויוצרים את הענף production.

cd ~
gcloud source repos clone hello-cloudbuild-env
cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
git checkout -b production

מעתיקים את הקובץ cloudbuild-delivery.yaml שזמין במאגר hello-cloudbuild-app ושומרים את השינוי.

cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
cp ~/hello-cloudbuild-app/cloudbuild-delivery.yaml ~/kubernetes-engine-samples/management/gitops-style-delivery/cloudbuild.yaml
git add .
git commit -m "Create cloudbuild.yaml for deployment"

בקובץ cloudbuild-delivery.yaml מתואר תהליך הפריסה שיופעל ב-Cloud Build. התהליך כולל שני שלבים:

‫Cloud Build מחיל את המניפסט על אשכול GKE.
אם הפעולה תצליח, Cloud Build יעתיק את המניפסט לענף הייצור.

steps:
# This step deploys the new version of our container image
# in the hello-cloudbuild Kubernetes Engine cluster.
- name: 'gcr.io/cloud-builders/kubectl'
  id: Deploy
  args:
  - 'apply'
  - '-f'
  - 'kubernetes.yaml'
  env:
  - 'CLOUDSDK_COMPUTE_REGION=us-central1'
  - 'CLOUDSDK_CONTAINER_CLUSTER=hello-cloudbuild'

# This step copies the applied manifest to the production branch
# The COMMIT_SHA variable is automatically
# replaced by Cloud Build.
- name: 'gcr.io/cloud-builders/git'
  id: Copy to production branch
  entrypoint: /bin/sh
  args:
  - '-c'
  - |
    set -x && \
    # Configure Git to create commits with Cloud Build's service account
    git config user.email $(gcloud auth list --filter=status:ACTIVE --format='value(account)') && \
    # Switch to the production branch and copy the kubernetes.yaml file from the candidate branch
    git fetch origin production && git checkout production && \
    git checkout $COMMIT_SHA kubernetes.yaml && \
    # Commit the kubernetes.yaml file with a descriptive commit message
    git commit -m "Manifest from commit $COMMIT_SHA
    $(git log --format=%B -n 1 $COMMIT_SHA)" && \
    # Push the changes back to Cloud Source Repository
    git push origin production

יוצרים ענף מועמד ומעבירים בדחיפה את שני הענפים כדי שהם יהיו זמינים ב-Cloud Source Repositories.
```
git checkout -b candidate
git push origin production
git push origin candidate
```

מקצים לחשבון השירות של Cloud Build את התפקיד Source Repository Writer (כותב במאגר קוד מקור) ב-IAM עבור מאגר hello-cloudbuild-env.

PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} \
    --format='get(projectNumber)')"
cat >/tmp/hello-cloudbuild-env-policy.yaml <<EOF
bindings:
- members:
  - serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com
  role: roles/source.writer
EOF
gcloud source repos set-iam-policy \
    hello-cloudbuild-env /tmp/hello-cloudbuild-env-policy.yaml

יצירת הטריגר לצינור העברת נתונים רציפה

בקטע הזה, מגדירים את Cloud Build כך שיופעל על ידי פעולת push להסתעפות candidate במאגר hello-cloudbuild-env.

פותחים את הדף Triggers של Cloud Build.

כניסה לדף Triggers
לוחצים על Create trigger (יצירת ביטוי להפעלה).
ממלאים את האפשרויות הבאות:
- בשדה שם, מקלידים hello-cloudbuild-deploy.
- בקטע Event, בוחרים באפשרות Push to a branch.
- בקטע Source, בוחרים באפשרות hello-cloudbuild-env בתור Repository ובאפשרות ^candidate$ בתור Branch.
- בקטע Configuration, בוחרים באפשרות Cloud Build קובץ תצורה (yaml או json).
- בשדה מיקום קובץ התצורה של Cloud Build, מקלידים cloudbuild.yaml אחרי /.
לוחצים על יצירה.

שינוי צינור עיבוד הנתונים של האינטגרציה הרציפה כדי להפעיל את צינור עיבוד הנתונים של הפיתוח הרציף

בסעיף הזה מוסיפים כמה שלבים לצינור האינטגרציה הרציפה שיוצר גרסה חדשה של מניפסט Kubernetes ושולח אותה למאגר hello-cloudbuild-env כדי להפעיל את צינור הפיתוח הרציף.

מחליפים את הקובץ cloudbuild.yaml בדוגמה המורחבת בקובץ cloudbuild-trigger-cd.yaml.

cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
cp cloudbuild-trigger-cd.yaml cloudbuild.yaml

קובץ cloudbuild-trigger-cd.yaml הוא גרסה מורחבת של קובץ cloudbuild.yaml. הוא מוסיף שלבים ליצירת מניפסט Kubernetes חדש ולהפעלת צינור העברת הנתונים הרציפה.

# This step clones the hello-cloudbuild-env repository
- name: 'gcr.io/cloud-builders/gcloud'
  id: Clone env repository
  entrypoint: /bin/sh
  args:
  - '-c'
  - |
    gcloud source repos clone hello-cloudbuild-env && \
    cd hello-cloudbuild-env && \
    git checkout candidate && \
    git config user.email $(gcloud auth list --filter=status:ACTIVE --format='value(account)')

# This step generates the new manifest
- name: 'gcr.io/cloud-builders/gcloud'
  id: Generate manifest
  entrypoint: /bin/sh
  args:
  - '-c'
  - |
     sed "s/GOOGLE_CLOUD_PROJECT/${PROJECT_ID}/g" kubernetes.yaml.tpl | \
     sed "s/COMMIT_SHA/${SHORT_SHA}/g" > hello-cloudbuild-env/kubernetes.yaml

# This step pushes the manifest back to hello-cloudbuild-env
- name: 'gcr.io/cloud-builders/gcloud'
  id: Push manifest
  entrypoint: /bin/sh
  args:
  - '-c'
  - |
    set -x && \
    cd hello-cloudbuild-env && \
    git add kubernetes.yaml && \
    git commit -m "Deploying image us-central1-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:${SHORT_SHA}
    Built from commit ${COMMIT_SHA} of repository hello-cloudbuild-app
    Author: $(git log --format='%an <%ae>' -n 1 HEAD)" && \
    git push origin candidate

שומרים את השינויים ושולחים אותם אל Cloud Source Repositories.
```
cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
git add cloudbuild.yaml
git commit -m "Trigger CD pipeline"
git push google master
```
הפעולה הזו מפעילה את צינור עיבוד הנתונים של האינטגרציה הרציפה ב-Cloud Build.
בודקים את ה-build של האינטגרציה הרציפה.

כניסה ל-Cloud Build

מופיעות הגרסאות האחרונות שבוצעו והסתיימו במאגר hello-cloudbuild-app. אפשר ללחוץ על build כדי לעקוב אחרי ההרצה שלו ולבדוק את היומנים שלו. בשלב האחרון של צינור העיבוד הזה, המניפסט החדש נדחף למאגר hello-cloudbuild-env, וזה מפעיל את צינור העיבוד של הפיתוח הרציף.
בודקים את ה-build של הפיתוח הרציף.

כניסה ל-Cloud Build

מופיעים ה-builds שהרצתם לאחרונה והסתיימו במאגר hello-cloudbuild-env. אפשר ללחוץ על build כדי לעקוב אחרי ההרצה שלו ולבדוק את היומנים שלו.

בדיקת צינור עיבוד הנתונים כולו

צינור עיבוד הנתונים המלא של CI/CD מוגדר עכשיו. בקטע הזה, תבדקו את התהליך מקצה לקצה.

עוברים לדף GKE Services.

מעבר אל Google Kubernetes Engine Services

הרשימה מכילה שירות יחיד בשם hello-cloudbuild שנוצר על ידי build של פיתוח רציף שהושלם לאחרונה.
לוחצים על נקודת הסיום של השירות hello-cloudbuild. מופיע הכיתוב 'Hello World!‎'. אם אין נקודת קצה או אם מופיעה שגיאה של מאזן העומסים, יכול להיות שתצטרכו להמתין כמה דקות עד שמאזן העומסים יאותחל באופן מלא. אם צריך לעדכן את הדף, לוחצים על רענון.

ב-Cloud Shell, מחליפים את Hello World ב-Hello Cloud Build, גם באפליקציה וגם בבדיקת היחידה.

cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
sed -i 's/Hello World/Hello Cloud Build/g' app.py
sed -i 's/Hello World/Hello Cloud Build/g' test_app.py

שומרים ודוחפים את השינוי ל-Cloud Source Repositories.
```
git add app.py test_app.py
git commit -m "Hello Cloud Build"
git push google master
```
הפעולה הזו מפעילה את צינור עיבוד הנתונים המלא של CI/CD.
אחרי כמה דקות, טוענים מחדש את האפליקציה בדפדפן. מופיעה ההודעה Hello Cloud Build!‎.

בדיקת החזרה למצב הקודם

בקטע הזה, מבצעים חזרה לגרסת האפליקציה שבה מופיע הכיתוב Hello World!‎.

פותחים את מסוף Cloud Build למאגר hello-cloudbuild-env.

כניסה ל-Cloud Build
לוחצים על ה-build השני הכי עדכני שזמין.
לוחצים על Rebuild.
בסיום ה-build, טוענים מחדש את האפליקציה בדפדפן. ההודעה 'Hello World!‎' מופיעה שוב.

הסרת המשאבים

כדי לא לצבור חיובים לחשבון Google Cloud על המשאבים שבהם השתמשתם במדריך הזה, אתם יכולים למחוק את הפרויקט שמכיל את המשאבים או להשאיר את הפרויקט ולמחוק את המשאבים בנפרד.

זהירות: כשמוחקים פרויקט:

התוכן של הפרויקט נמחק כולו. אם השתמשתם בפרויקט קיים כדי לתרגל את המשימות במדריך הזה, כשתמחקו אותו תימחק גם כל העבודה שביצעתם באותו פרויקט.
מאבדים את מזהה הפרויקט בהתאמה אישית. כשיצרתם את הפרויקט, יכולתם לבחור לו מזהה פרויקט בהתאמה אישית כדי להשתמש בו בעתיד. כדי לשמור על כתובות ה-URL שמשתמשות במזהה הפרויקט, כמו appspot.com, צריך למחוק את המשאבים שנבחרו בפרויקט אבל לא את הפרויקט כולו.

אם אתם מתכננים להיעזר בכמה ארכיטקטורות, מדריכים או מדריכים למתחילים, מומלץ להשתמש שוב באותו פרויקט כדי לא לחרוג ממכסות הפרויקטים.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

מחיקת המשאבים

אם אתם רוצים לשמור את הפרויקט שבו השתמשתם במדריך הזה, אתם צריכים למחוק את המשאבים הבודדים: Google Cloud

מחיקת מאגרי Git מקומיים.

cd ~
rm -rf ~/hello-cloudbuild-app
rm -rf ~/hello-cloudbuild-env

מוחקים את מאגרי ה-Git ב-Cloud Source Repositories.

gcloud source repos delete hello-cloudbuild-app --quiet
gcloud source repos delete hello-cloudbuild-env --quiet

מוחקים את הטריגרים של Cloud Build.
1. פותחים את הדף Triggers של Cloud Build.
  
  כניסה לדף Triggers
2. לכל טריגר, לוחצים על סמל האפשרויות הנוספות ואז על מחיקה.

מחיקת מאגר Docker ב-Artifact Registry.

gcloud artifacts repositories delete my-repository \
    --location=us-central1

מסירים את ההרשאה שניתנה ל-Cloud Build להתחבר ל-GKE.

PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} \
    --format='get(projectNumber)')"
gcloud projects remove-iam-policy-binding ${PROJECT_NUMBER} \
    --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
    --role=roles/container.developer

מוחקים את אשכול GKE.

gcloud container clusters delete hello-cloudbuild \
   --location us-central1

המאמרים הבאים

כדאי לבדוק את התכונות המתקדמות יותר ב-Cloud Build: הגדרת סדר השלבים של ה-build, יצירה, בדיקה ופריסה של ארטיפקטים, וגם יצירת שלבים מותאמים אישית של build.
איך משכפלים מאגר GitHub או Bitbucket ל-Cloud Source Repositories
חיבור Cloud Build ישירות למאגר שלכם ב-GitHub