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

בדף הזה מוסבר איך להשתמש בתהליך עבודה של 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 היא מערכת למתן שמות ל-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:

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

שימוש במשקפיים

כל מפתח יכול להשתמש ב-Spectacles כדי לאמת את השינויים שלו בזמן שהם עדיין בענף הפיתוח. ‫Spectacles מציע ארבעה סוגים שונים של כלים לאימות:

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

SQL Validator

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

$ spectacles sql --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --explores MODEL_NAME/EXPLORE_NAME \
    --branch DEV_BRANCH_NAME

לדוגמה:

$ spectacles sql --config-file config-dev.yaml \
    --project thelook_cicd \
    --explores thelook_cicd/users \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0

=================== Testing 1/1 explores [concurrency = 10] ===================

✓ thelook_cicd.users passed

Completed SQL validation in 1 minute and 7 seconds.

מאמת LookML

כלי התיקוף של LookML מוודא ששינויים ב-LookML הם תקינים ואין בהם שגיאות תחביר. הקריאה לפונקציה מתבצעת כך:

$ spectacles lookml --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --branch DEV_BRANCH_NAME

לדוגמה:

$ spectacles lookml --config-file config-dev.yaml \
    --project thelook_cicd \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0

============= Validating LookML in project thelook_cicd [warning] ==============

✗ thelook_cicd/business_pulse.dashboard.lookml failed
✗ thelook_cicd/thelook_cicd.model.lkml failed

================ thelook_cicd/business_pulse.dashboard.lookml:28 ===============

[Error] Unknown field "users.state" in explore "users" for field_filter.

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/business_pulse.dashboard.lookml?line=28

================ thelook_cicd/business_pulse.dashboard.lookml:36 ===============

[Warning] Unknown field "users.state" (for explore "orders" in model
"thelook_cicd") referenced in dashboard element.

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/business_pulse.dashboard.lookml?line=36

[Additional errors snipped]

Completed validation in 6 seconds.

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

כלי אימות התוכן בודק שכל התוכן השמור, כמו מראה ולוחות בקרה מוגדרים על ידי המשתמש (UDD), עדיין פועל אחרי ביצוע שינויים. כדי שהעבודה תרוץ מהר יותר ותספק תוצאות שקל לנהל, האימות מתבצע רק לגבי תוכן שמבוסס על ניתוחים שאתם מציינים. הקריאה ל-כלי לאימות התוכן מתבצעת באופן הבא:

$ spectacles content --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --explores MODEL_NAME/EXPLORE_NAME \
    --branch DEV_BRANCH_NAME

לדוגמה:

$ spectacles content --config-file config-dev.yaml \
    --project thelook_cicd \
    --explores thelook_cicd/users \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0
Building LookML project hierarchy for project 'thelook_cicd' @ dev-my-user-ydnv

==================== Validating content based on 5 explores ====================

✗ thelook_cicd.users failed

================= test dashboard for spectacles [TheLook_CICD] =================

Tile 'test dashboard for spectacles' failed validation.

Error in thelook_cicd/users: Unknown field "users.state".

Dashboard: https://gcpl2318.cloud.looker.com/dashboards/223

========================= Business Pulse [TheLook_CICD] ========================

Filter 'State / Region' failed validation.

Error in thelook_cicd/users: Unknown field "users.state".

Dashboard: https://gcpl2318.cloud.looker.com/dashboards/190

Completed content validation in 27 seconds.

אימות טענה לבעלות

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

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

האימות של הצהרת ה-Assert מופעל כמו שמוצג בהמשך:

$ spectacles assert --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --explores MODEL_NAME/EXPLORE_NAME \
    --branch DEV_BRANCH_NAME

לדוגמה:

$ spectacles assert --config-file config-dev.yaml \
    --project thelook_cicd \
    --explores thelook_cicd/users \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0
Building LookML project hierarchy for project 'thelook_cicd' @ dev-my-user-ydnv

==================== Running data tests based on 1 explore =====================

✗ thelook_cicd.users failed

================ thelook_cicd/users/california_users_is_accurate ===============

Unknown filter field "users.state" in lookml test "california_users_is_accurate"
declaration.

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/thelook_cicd.model.lkml?line=55

================ thelook_cicd/users/california_users_is_accurate ===============

Invalid filter: users.state

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/thelook_cicd.model.lkml?line=55

================ thelook_cicd/users/california_users_is_accurate ===============

Assertion "count_is_expected_value" failed: expression evaluated to "No".

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/thelook_cicd.model.lkml?line=55

Completed data test validation in 14 seconds.

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

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

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

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

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

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

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

gzr dashboard sync_lookml DASHBOARD_ID --host TARGET_SYSTEM_URL

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

אפשר להעביר מרכזי בקרה מוגדרים על ידי משתמש (UDD) באמצעות Gazer על ידי הפניה למזהה של מרכז הבקרה ולכתובת ה-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