בדף הזה מוסבר איך להשתמש בתהליך עבודה של CI/CD ב-Looker אחרי שמתקינים ומגדירים תהליך עבודה כזה.
בהוראות האלה אנחנו משתמשים במערכת תלת-שכבתית שכוללת פיתוח, אבטחת איכות וייצור. עם זאת, אפשר להחיל את אותם עקרונות על מערכת עם שתי רמות או ארבע רמות.
בנוסף, אנחנו מניחים שאתם משתמשים ב-GitHub כספק Git. אפשר להשתמש בספקי Git אחרים כדי ליצור תהליך עבודה של CI/CD, אבל צריך להיות לכם את הידע הנדרש כדי לשנות את ההוראות האלה בהתאם לספק שלכם.
סקירה כללית של תהליך העבודה
מפתחי LookML מתחילים בכתיבת קוד בהסתעפות הפיתוח שלהם, שבדרך כלל נקראת משהו כמו dev-my-user-ydnv, בודקים את השינויים שלהם באמצעות Spectacles ומבצעים commit של הקוד. לבסוף, הם פותחים בקשת משיכה כדי למזג את הקוד שלהם עם הענף main.
כשפותחים את בקשת המיזוג, המפתח מועבר ל-GitHub. המפתח צריך לכתוב כותרת משמעותית לבקשת מיזוג באמצעות סגנון של conventional commits ולהוסיף תגובה לתיאור שתצורף ליומן השינויים. צריך להוסיף את תוצאות הבדיקות של Spectacles כתגובות לבקשת משיכת השינויים.
לאחר מכן, המפתח צריך לבחור בודק ב-GitHub. כותב הביקורת יקבל התראה ויוכל להוסיף את הביקורת שלו לבקשת מיזוג. אם הבודק מאשר את השינוי, בקשת ה-PR מתמזגת עם הענף main. מבוצעת קריאה ל-WebHook וסביבת הפיתוח רואה את השינוי.
באופן אוטומטי, האוטומציה של Release Please תפעל ותפתח בקשת מיזוג שנייה כדי ליצור גרסה מתויגת חדשה. לחלופין, אם כבר קיימת בקשת משיכה למטרה הזו, Release Please מעדכן את בקשת המשיכה הזו. ל-PR של הגרסה יש מספר גרסה שמשויך אליו, וגם יומן שינויים שכולל את השמות והתיאורים של השינויים שנכללים בו.
כשבקשת משיכה שנוצרה על ידי Release Please מאושרת וממוזגת, נוצר תג גרסה חדש ויומן השינויים ממוזג עם הענף main. במופעי QA וייצור של Looker אפשר לבחור את הגרסה הזו באמצעות מצב פריסה מתקדם.
שיטות מומלצות למספור גרסאות ולמתן שמות לקומיטים
אפשר לתת לשחרורים ולתגים המשויכים להם שמות ומספרים בכל דרך שנראית לכם הגיונית בסביבה שלכם. עם זאת, מומלץ מאוד להשתמש בניהול גרסאות סמנטי, כי הוא פועל בצורה טובה עם התוסף Release Please.
בגרסה הסמנטית יש שלושה מספרים שמופרדים בנקודות: MAJOR.MINOR.PATCH
- הערך
PATCHגדל בכל פעם שמתקנים באג בגרסה - הערך של
MINORגדל והערך שלPATCHמתאפס בכל פעם שמוסיפים תכונה למהדורה או משפרים אותה, תוך שמירה על תאימות לאחור - הערך של
MAJORגדל, והערכים שלMINORו-PATCHמוגדרים לאפס כשמוסיפים תכונה שלא תואמת לאחור
Conventional Commits היא מערכת למתן שמות לקומיטים לפי ההשפעה שלהם על משתמשי הקצה. השימוש בשמות קונבנציונליים של קומיטים לא נדרש, אבל הוא מועיל גם לפלאגין Release Please.
בשיטה המקובלת למתן שמות לקומיטים, לכל הודעת קומיט מתווסף בתחילת ההודעה אינדיקטור להיקף השינוי:
- תיקון באג מסומן בסימן
fix:, כמוfix: set proper currency symbol on sale_amt format - תכונה חדשה מסומנת בסמל
feat:, כמוfeat: added explore for sales by territory - תכונה עם שינוי שעלול לשבור את התאימות מסומנת בסמל
feat!:, כמוfeat!: rewrote sales explore to use the new calendar view - כשמעדכנים את התיעוד אבל לא משנים את קוד LookML, הודעת ה-commit מתחילה ב-
doc:
אם משתמשים בהודעות קומיט קונבנציונליות באופן עקבי, בדרך כלל קל לקבוע את המספר הסמנטי שבו צריך להשתמש בהמשך. אם יומן השליחות מורכב רק משליחות fix: ו-doc:, צריך להגדיל את הערך של PATCH. אם יש פעולת commit של feat:, צריך להגדיל את הערך של MINOR. אם יש feat!:, צריך להגדיל את הערך של MAJOR. הפלאגין Release Please יכול אפילו ליצור קובץ CHANGELOG ולתייג את הגרסה באופן אוטומטי.
שימוש במצב פריסה מתקדם
אחרי שמבצעים שינויים ושולחים אותם כבקשת משיכה במופע הפיתוח, התוסף Release Please יתייג את השינויים בתג גרסה כמו v1.2.3. מצב הפריסה המתקדם של Looker מאפשר להשתמש בגרסאות האלה בממשק המשתמש של Looker עבור מופעי QA וייצור.
כדי לפרוס שינוי, בוחרים את Deployment Manager מתוך Looker IDE:
בפינה השמאלית העליונה של Deployment Manager, לוחצים על הקישור Select Commit (בחירת פעולת Commit). לאחר מכן, לוחצים על סמל האפשרויות הנוספות (3 נקודות) שמשויך לתג שרוצים להטמיע, ובוחרים באפשרות הטמעה בסביבה:
אין צורך לתייג את הפריסה שוב, לכן בוחרים באפשרות Deploy without tagging (פריסה ללא תיוג) ולוחצים על הלחצן Deploy to Environment (פריסה לסביבה):
לבסוף, דוחפים את השינויים לסביבת הייצור באמצעות Deployment Manager.