שימוש ב-CI/CD ב-Looker ותהליך עבודה מרובה-שכבות

בדף הזה מוסבר איך להשתמש בתהליך עבודה של CI/CD מרובה-רמות ב-Looker אחרי ההתקנה וההגדרה של תהליך העבודה.

בהוראות האלה אנחנו משתמשים במערכת תלת-שכבתית שכוללת פיתוח, בקרת איכות וייצור. עם זאת, אפשר להחיל את אותם עקרונות על מערכת עם שתי רמות או ארבע רמות.

בנוסף, אנחנו מניחים שאתם משתמשים ב-GitHub כספק Git. אפשר להשתמש בספקי Git אחרים כדי ליצור תהליך עבודה של CI/CD, אבל תצטרכו להיות מומחים כדי לשנות את ההוראות האלה בהתאם לספק שלכם.

סקירה כללית של תהליך העבודה

מפתחי LookML מתחילים בכתיבת קוד בענף הפיתוח שלהם, שבדרך כלל נקרא dev-my-user-ydnv, בודקים את השינויים שלהם באמצעות Looker Continuous Integration (או באמצעות הפעלה ידנית של חבילת CI) ומבצעים commit לקוד שלהם. לבסוף, הם פותחים בקשת משיכה כדי למזג את הקוד שלהם עם הענף main.

כשבקשת המיזוג נפתחת, המפתח מועבר אל GitHub. המפתח צריך לכתוב כותרת משמעותית לבקשת משיכת הקוד באמצעות סגנון של conventional commits ולהוסיף תגובה לתיאור שתצורף ליומן השינויים. אם מוגדר הפעלה של בקשות משיכה, שילוב Looker Continuous Integration מאמת באופן אוטומטי את בקשת המשיכה, ומפתחים יכולים לראות את התוצאות ב-Looker או ב-GitHub.

לאחר מכן, המפתח צריך לבחור בודק ב-GitHub. כותב הביקורת יקבל התראה ויוכל להוסיף את הביקורת שלו לבקשת משיכת השינויים. אם הבודק מאשר את השינוי, בקשת משיכת השינויים מתמזגת עם הענף 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 היא מערכת למתן שמות ל-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, הודעת השמירה מתחילה במילים doc:

אם משתמשים באופן עקבי בהודעות קומיט קונבנציונליות, בדרך כלל קל לקבוע את המספר הסמנטי שבו צריך להשתמש בהמשך. אם יומן השליחות מורכב רק משליחות fix: ו-doc:, צריך להגדיל את הערך של PATCH. אם יש feat: commit, צריך להגדיל את MINOR. אם יש feat!:, צריך להגדיל את הערך של MAJOR. התוסף Release Please יכול אפילו ליצור קובץ CHANGELOG ולתייג את הגרסה באופן אוטומטי.

שימוש במצב פריסה מתקדם

אחרי שמבצעים שינויים ושולחים אותם כבקשת מיזוג במופע הפיתוח, התוסף Release Please יתייג את השינויים בתג גרסה כמו v1.2.3. לאחר מכן, מצב הפריסה המתקדם של Looker מאפשר להשתמש בגרסאות האלה בממשק המשתמש של Looker עבור מופעי QA וייצור.

כדי לפרוס שינוי, בוחרים ב-Deployment Manager מתוך Looker IDE:

המיקום של Looker Deployment Manager ב-IDE.

בפינה השמאלית העליונה של Deployment Manager, לוחצים על הקישור Select Commit (בחירת פעולת Commit). לאחר מכן, לוחצים על סמל האפשרויות הנוספות (3 נקודות) שמשויך לתג שרוצים להטמיע, ובוחרים באפשרות הטמעה בסביבה:

ממשק המשתמש של Looker Deployment Manager לפריסה בסביבה.

אין צורך לתייג את הפריסה שוב, לכן בוחרים באפשרות Deploy without tagging (פריסה ללא תיוג) ולוחצים על הלחצן Deploy to Environment (פריסה לסביבה):

ממשק המשתמש של Looker Deployment Manager לפריסה ללא תיוג.

לבסוף, דוחפים את השינויים לסביבת הייצור באמצעות Deployment Manager.

שימוש באינטגרציה רציפה של Looker

כדי לאמת שינויים בענף פיתוח או כחלק מבקשת משיכה, מפתחים יכולים להשתמש ב-Looker Continuous Integration. האינטגרציה הרציפה מספקת את אמצעי האימות הבאים:

  • כלי לאימות SQL – מאמת שהמאפיינים בדוחות שלכם פועלים בצורה תקינה מול מסד הנתונים.
  • ‫Assert Validator – מריץ את כל בדיקות הנתונים של LookML שנוצרו על ידי מפתחי Looker ומחזיר את כל הכשלים והשגיאות.
  • ‫Content Validator (כלי לאימות תוכן) – מריץ את אימות התוכן של Looker כדי לבדוק אם יש שגיאות בדוחות ובמרכזי הבקרה בפרויקט של LookML.
  • LookML Validator (כלי האימות של LookML) – מריץ את LookML Validator (כלי האימות של LookML) כדי לבדוק אם יש שגיאות LookML בפרויקט.
  • ‫Style Validator – מאכף את תקני הקידוד של LookML, מוסכמות השמות ושיטות מומלצות מבניות בפרויקט.

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

SQL Validator

כלי האימות של SQL בשילוב רציף מוודא שהמאפיינים ב-Explores פועלים בצורה תקינה מול מסד הנתונים. הבדיקה הזו בודקת אם שדות שמוגדרים בתצוגות LookML תואמים לעמודות או לביטויים תקפים של SQL במסד הנתונים.

הכלי לאימות SQL כולל את היכולות העיקריות הבאות:

מידע נוסף ואפשרויות הגדרה מופיעים בדף התיעוד בנושא כלי התיקוף של SQL בשילוב רציף.

כלי האימות של LookML

כלי האימות של LookML בשילוב מתמשך בודק את פרויקט LookML שלכם כדי לזהות שגיאות תחביר, כמו סוגריים חסרים או הפניות לא תקינות לשדות. הכלי הזה שימושי במיוחד למפתחים שכותבים LookML מחוץ לסביבת הפיתוח המשולבת (IDE) של Looker.

הכלי לאימות LookML כולל את היכולות העיקריות הבאות:

  • מאפשר להגדיר סף חומרה (שגיאה, אזהרה או מידע) שקובע איזו רמת חומרה של הודעה גורמת לביטול ההרצה.
  • מאפשרת להגדיר משך זמן קצוב לתפוגה להרצות אימות.

מידע נוסף ואפשרויות הגדרה מופיעים בדף התיעוד בנושא כלי האימות של LookML לשילוב רציף.

כלי לאימות התוכן

כלי לאימות התוכן של אינטגרציה רציפה (CI) מוודא שתוכן שנשמר, כמו טבלאות Look ולוחות בקרה בהגדרת המשתמש (UDD), עדיין פועל בצורה תקינה אחרי שמבצעים שינויים ב-LookML.

היכולות העיקריות של הכלי לאימות התוכן:

מידע נוסף ואפשרויות הגדרה מופיעים בדף התיעוד בנושא כלי לאימות תוכן של שילוב רציף.

כלי לאימות טענות

הכלי לאימות טענות של שילוב רציף מפעיל בדיקות נתונים של LookML שמוגדרות בפרויקט כדי לאמת את הלוגיקה של המודל ואת שלמות הנתונים.

לדוגמה, בדיקת נתונים ב-LookML יכולה להיראות כך:

test: historic_revenue_is_accurate {
  explore_source: orders {
    column: total_revenue { field: orders.total_revenue }
    filters: [orders.created_date: "2024"]
  }
  assert: revenue_is_expected_value {
    expression: ${orders.total_revenue} = 626000 ;;
  }
}

הכלי לאימות טענות כולל את היכולות העיקריות הבאות:

מידע נוסף ואפשרויות הגדרה מופיעים בדף מאמרי העזרה בנושא כלי התיקוף של טענות נכוֹנוּת של אינטגרציה רציפה (CI).

ניהול והרצה של חבילות בדיקה של CI

כדי לנהל ולהריץ בדיקות של שילוב רציף, פועלים לפי השלבים הבאים:

כברירת מחדל, ל-Looks ולמרכזי בקרה מוקצים מזהים מספריים בסדר עולה, שמשמשים בכתובת ה-URL של ה-Look או מרכז הבקרה. עם זאת, אין דרך לשמור על סנכרון בין המערכות. לכן, כתובת URL של לוח בקרה ספציפי שנמצא בפיתוח לא תפנה לאותו לוח בקרה בבדיקת איכות או בייצור.

ב-UDD יש אפשרות להשתמש בסלאג במקום במזהה כחלק מכתובת ה-URL. הסלאג הוא קבוצה של תווים שהיא אקראית למחצה, ולא מספר. אפשר להגדיר את ה-slug כחלק מהייבוא, כך שכתובת URL דומה תפנה לאותו UDD בסביבות פיתוח, QA וייצור. שימוש בסלאגים במקום במזהים הוא שיטה מומלצת, במיוחד כשמבצעים 'קליק למעבר' ל-UDD מ-Look או מ-UDD אחר.

אפשר למצוא את ה-slug על ידי בדיקת הפלט של gzr dashboard cat. אפשר להשתמש בסלאג בכתובת ה-URL של מרכז הבקרה במקום במזהה המספרי.

העברת תוכן משתמשים באמצעות Gazer

לעתים קרובות כדאי להעתיק תוכן כמו Look ולוחות בקרה בין סביבות הפיתוח, בקרת האיכות והייצור. יכול להיות שתרצו ליצור תוכן שמציג תוספות חדשות ל-LookML, או לוודא שתוכן שמור עדיין פועל בצורה תקינה אחרי שינויים ב-LookML. במקרים כאלה אפשר להשתמש ב-Gazer כדי להעתיק תוכן בין מופעים.

מרכזי בקרה של LookML

מרכזי שליטה של LookML מסתנכרנים בין מופעים במהלך תהליך העבודה הרגיל של LookML CI/CD. עם זאת, אם יש לוחות בקרה של UDD שמסונכרנים עם לוחות בקרה של LookML, אפשר לעדכן אותם באמצעות Gazer באמצעות הפקודה הבאה:

gzr dashboard sync_lookml DASHBOARD_ID --host TARGET_SYSTEM_URL

מרכזי בקרה בהגדרת המשתמש

אפשר להעביר ל-Gazer לוחות בקרה שהוגדרו על ידי המשתמש (UDD) על ידי הפניה למזהה של לוח הבקרה ולכתובת ה-URL של מופע Looker שבו נמצא לוח הבקרה. Gazer שומר את הגדרות לוח הבקרה בקובץ JSON, ואז מייבא אותו למופע היעד של Looker.

הפקודה לחילוץ הגדרות ה-UDD היא:

gzr dashboard cat DASHBOARD_ID --host TARGET_SYSTEM_URL --dir .

פעולה זו תיצור קובץ בשם Dashboard_DASHBOARD_ID_DASHBOARD_NAME.json שמכיל את ההגדרה של לוח הבקרה.

אפשר לייבא את ה-UDD למערכת היעד באמצעות הפקודה הבאה:

gzr dashboard import Dashboard_DASHBOARD_ID_DASHBOARD_NAME.json FOLDER_ID \
    --host TARGET_SYSTEM_URL

תבניות עיצוב

העברת מראה פועלת באופן דומה מאוד להעברת UDD. קודם כל, משתמשים ב-Gazer כדי לשמור את הגדרות ה-Look בקובץ JSON:

gzr look cat LOOK_ID --host SOURCE_SYSTEM_URL --dir .

לאחר מכן, מייבאים את ה-Look למופע היעד:

gzr look import Look_LOOK_ID_LOOK_NAME.json FOLDER_ID \
    --host TARGET_SYSTEM_URL