בדף הזה מוסבר איך להתקין ולהגדיר את הרכיבים הנדרשים כדי להטמיע תהליך עבודה של CI/CD רב-שכבתי ב-Looker.
בהוראות האלה אנחנו משתמשים במערכת תלת-שכבתית שכוללת פיתוח, בקרת איכות וייצור. עם זאת, אפשר להחיל את אותם עקרונות על מערכת עם שתי רמות או ארבע רמות.
בנוסף, אנחנו מניחים שאתם משתמשים ב-GitHub כספק Git. אפשר להשתמש בספקי Git אחרים כדי ליצור תהליך עבודה של CI/CD, אבל תצטרכו להיות מומחים כדי לשנות את ההוראות האלה בהתאם לספק שלכם.
פועלים לפי ההוראות בקטע שרלוונטי לכם:
דרישות מוקדמות
סביבת Linux
בתהליך הזה נעשה שימוש בכלי שנקרא Gazer, שמיועד למערכות הפעלה דמויות Unix. לכל מפתח LookML שצריך לבצע מיגרציה של תוכן משתמשים צריכה להיות גישה לשורת הפקודה בסביבת Linux או macOS שבה אתם מתכננים להפעיל את תהליך העבודה של CI/CD.
אם אתם משתמשים ב-Windows, אפשר להשתמש ב-Gazer בתוך Windows Subsystem For Linux (WSL) של מיקרוסופט. באמצעות WSL אפשר להריץ מגוון טעמים שונים של לינוקס. אם אין לכם מערכת הפעלה מועדפת של Linux, כדאי לבחור בגרסה האחרונה של Ubuntu Linux כי יש לה תמיכה רחבה.
ההוראות האלה כוללות דוגמאות למערכות Linux, ויכול להיות שתצטרכו לשנות אותן אם אתם משתמשים ב-macOS או ב-WSL.
מופע אחד של Looker לכל רמה
כדי להפעיל את ההגדרה הזו, תצטרכו מכונה אחת של Looker לכל רמה במערכת. לדוגמה, מערכת עם שלב פיתוח, שלב QA ושלב ייצור תצטרך שלוש דוגמאות נפרדות. יכול להיות שהמופעים יתארחו על ידי Google או באירוח בצד הלקוח.
שמות חיבור זהים
חיבורי מסד נתונים צריכים להיות בעלי אותו שם בכל מופע של Looker, ללא קשר לרמה שהם מייצגים. לדוגמה, אם שם החיבור הוא sales, הוא צריך להופיע בכל המקרים ולא sales_dev או sales_qa.
החיבורים יכולים להפנות לאותו מסד נתונים או למסדי נתונים שונים. עם זאת, אם הם מצביעים על אותו מסד נתונים, צריך להגדיר להם סכימות שונות של טבלאות זמניות כדי שטבלאות נגזרות קבועות במופע הפיתוח או במופע QA לא יפריעו לייצור.
לדוגמה, אם משתמשים באותו מסד נתונים לכל שלושת המופעים, יכול להיות שהם יוגדרו כך:
| Production | QA | Development | |
| שם החיבור | sales |
sales |
sales |
| מסד נתונים | sales_db |
sales_db |
sales_db |
| Scratch Schema | prod_sales_scratch |
qa_sales_scratch |
dev_sales_scratch |
לחלופין, אם משתמשים במסד נתונים ייחודי לכל שלושת המקרים, יכול להיות שהם יוגדרו באופן הבא:
| Production | QA | Development | |
| שם החיבור | sales |
sales |
sales |
| מסד נתונים | sales_db_prod |
sales_db_qa |
sales_db_dev |
| Scratch Schema | sales_scratch |
sales_scratch |
sales_scratch |
מאגר Git
מאגר git יחיד ישמש לכל פרויקט בכל שלוש הרמות. מופע הפיתוח יעקוב אחרי הענף main, בעוד שמופעי בקרת האיכות והייצור בדרך כלל יצביעו על תגי git (שמתוארים בפירוט בהמשך).
שלבי הגדרה שצריך לבצע רק בפעם הראשונה
רק משתמשים עם הרשאות אדמין ב-Looker והרשאות אדמין בספק git יכולים לבצע את השלבים שבקטע הזה, וצריך לבצע אותם רק פעם אחת.
פרטי כניסה ל-Git
סביבת ה-Linux של כל מפתח צריכה להתחבר לאותו מאגר שבו אתם משתמשים כדי לנהל את LookML. סביר להניח שמדובר במאגר חיצוני שמתארח בשירות כמו GitHub. תצטרכו חשבון בשירות הזה עם פרטי הכניסה המתאימים כדי להגדיר את המאגר. באמצעות החשבון, אפשר להגדיר מפתח SSH כדי לאפשר לסביבת Linux להתחבר לשירות הזה באופן אוטומטי.
ב-GitHub, פועלים לפי ההוראות במאמר Adding a new SSH key to your GitHub account.
יצירה והגדרה של מאגר שרת Git
כדי שתהליך העבודה של CI/CD יפעל, צריך לאחסן את LookML במאגר git ולקשר אותו לפרויקט Looker. בהגדרות הפרויקט, צריך להגדיר את שם ענף הייצור של Git ל-main ולהפעיל את הפעלת מצב פריסה מתקדם.
אם עדיין לא ביצעתם את השלבים הבאים, אתם צריכים לפעול לפי ההוראות האלה ל-GitHub:
יצירת מאגר חדש
- בממשק המשתמש של GitHub, לוחצים על הלחצן + בפינה השמאלית העליונה ואז בוחרים באפשרות New repository (מאגר חדש).
- בוחרים את הבעלים (בדרך כלל הארגון שלכם) ומזינים REPOSITORY_NAME.
- בוחרים אם להגדיר את המאגר כציבורי או פרטי (מאגרים פרטיים דורשים מינוי בתשלום ל-GitHub), ומסמנים את התיבה כדי לאתחל אותו באמצעות קובץ README.
- לוחצים על הלחצן Create repository (יצירת מאגר).
- לוחצים על הכפתור הירוק <> Code ומעתיקים את כתובת ה-URL של ה-SSH. היא תיראה בערך כך:
git@github.com:org_name/REPOSITORY_NAME.git. - ב-Looker, יוצרים פרויקט חדש.
- נכנסים למצב פיתוח, בוחרים את הפריט 'הגדרות הפרויקט' בסרגל הצד הימני ואז לוחצים על הגדרת Git.
- מדביקים את כתובת ה-URL של המאגר (
git@github.com:org_name/REPOSITORY_NAME.gitבדוגמה הזו) ולוחצים על המשך. - מעתיקים את מפתח הפריסה וחוזרים לממשק המשתמש של GitHub עבור המאגר הזה.
- בוחרים באפשרות הגדרות ואז באפשרות פעולות – כללי.
- בקטע Workflow permissions (הרשאות של תהליך העבודה), מוודאים שהתיבה Allow GitHub Actions to create and approve pull requests (מתן הרשאה לפעולות GitHub ליצור ולאשר בקשות משיכה) מסומנת ולוחצים על Save (שמירה).
- עוברים לדף Deploy keys (מפתחות פריסה) בהגדרות של GitHub.
- לוחצים על הלחצן Add deploy key (הוספת מפתח פריסה) ומדביקים את מפתח הפריסה בשדה Key (מפתח).
- מוסיפים שם כמו
Looker-REPOSITORY_NAME, מסמנים את התיבה Allow write access ולוחצים על הכפתור Add key. - חוזרים אל Looker ובוחרים באפשרות בדיקה וסיום ההגדרה.
- בסרגל הצד הימני, בוחרים שוב את הגדרות הפרויקט. משנים את Git Production Branch Name ל-
main. - בוחרים באפשרות Enable Advanced Deploy Mode (הפעלת מצב פריסה מתקדם) ולוחצים על Save Project Configuration (שמירת הגדרות הפרויקט).
מתחת לסמל של הגדרות הפרויקט בצד ימין, אמור להופיע סמל הפריסה של Deployment Manager.
שימוש במאגר קיים
- עוברים למאגר GitHub שבו מאוחסן קוד LookML. (כאן מזינים את שם המאגר: REPOSITORY_NAME).
- בוחרים באפשרות הגדרות ואז באפשרות פעולות – כללי.
- בקטע Workflow permissions (הרשאות של תהליך העבודה), מוודאים שהתיבה Allow GitHub Actions to create and approve pull requests (מתן הרשאה לפעולות GitHub ליצור ולאשר בקשות משיכה) מסומנת ולוחצים על Save (שמירה).
- עוברים לקטע <> Code במאגר ב-GitHub.
- לוחצים על הכפתור הירוק <> Code ומעתיקים את כתובת ה-URL של ה-SSH. היא תיראה בערך כך:
git@github.com:org_name/REPOSITORY_NAME.git. - ב-Looker, יוצרים פרויקט חדש.
- נכנסים למצב פיתוח, בוחרים את הפריט 'הגדרות הפרויקט' בסרגל הצד הימני ואז לוחצים על הגדרת Git.
- מדביקים את כתובת ה-URL של המאגר (
git@github.com:org_name/REPOSITORY_NAME.gitבדוגמה הזו) ולוחצים על המשך. - מעתיקים את מפתח הפריסה וחוזרים לממשק המשתמש של GitHub עבור המאגר הזה.
- בוחרים באפשרות הגדרות ואז באפשרות פריסת מפתחות.
- לוחצים על הלחצן Add deploy key (הוספת מפתח פריסה) ומדביקים את מפתח הפריסה בשדה Key (מפתח).
- מוסיפים שם כמו
Looker-REPOSITORY_NAME, מסמנים את התיבה Allow write access ולוחצים על הכפתור Add key. - חוזרים אל Looker ובוחרים באפשרות בדיקה וסיום ההגדרה.
- בסרגל הצד הימני, בוחרים שוב את הגדרות הפרויקט. משנים את Git Production Branch Name ל-
main. - בוחרים באפשרות Enable Advanced Deploy Mode (הפעלת מצב פריסה מתקדם) ולוחצים על Save Project Configuration (שמירת הגדרות הפרויקט).
מתחת לסמל של הגדרות הפרויקט בצד ימין, אמור להופיע סמל הפריסה של Deployment Manager.
יצירת פעולות GitHub
מומלץ ליצור כמה פעולות ב-GitHub כדי שבכל פעם שמתבצעים שינויים ב-LookML, יתבצעו אוטומטית בדיקות שונות. כדי להוסיף את הפעולות האלה, צריך להיות לכם אפשרות לבצע שינויים במאגר Git בסביבת Linux. אם הוא עדיין לא זמין, פועלים לפי ההוראות שבקטע הגדרת Git.
כדי להוסיף את פעולות GitHub, עוברים לספרייה של המאגר בסביבת Linux ומוסיפים את ספריית המשנה .github/workflows. אחרי ההגדרה, אפשר להריץ את הפעולות האלה באופן ידני מהדף Actions בממשק המשתמש של GitHub.
Look-At-Me-Sideways (LAMS)
LAMS הוא כלי קוד פתוח לניתוח קוד, שבודק את קוד ה-LookML שלכם כדי לזהות שגיאות ושיטות עבודה לא מומלצות. מוסיפים קובץ בשם lams.yml לספרייה .github/workflows עם התוכן הבא:
name: LAMS
on:
pull_request:
branches: [ main ]
push:
workflow_dispatch:
jobs:
lams_job:
runs-on: ubuntu-latest
name: LAMS LookML Linter Job
steps:
- name: Checkout your LookML
uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }}
fetch-depth: 0
- name: Setup Node
uses: actions/setup-node@v1
with:
node-version: '16.x'
- name: Install LAMS
run: npm install -g @looker/look-at-me-sideways@3
- name: Run LAMS
run: lams --reporting=no
בכל פעם ששולחים commit ל-GitHub או פותחים בקשת משיכה כדי למזג קוד עם הסתעפות main, LAMS יפעל.
Release Please
Release Please הוא כלי בקוד פתוח שמתייג באופן אוטומטי מהדורות עם מספרי הגרסה המתאימים.
מוסיפים קובץ בשם release-please.yml לספרייה .github/workflows עם התוכן הבא:
name: release-please
on:
push:
branches:
- main
workflow_dispatch:
permissions:
contents: write
pull-requests: write
jobs:
release-please:
runs-on: ubuntu-latest
steps:
- uses: google-github-actions/release-please-action@v3
with:
release-type: simple
הודעות קומיט קונבנציונליות
פעולת GitHub הזו תאמת שבקשת משיכה נפתחה עם שם שתואם לתקן ההתחייבות המקובל.
מוסיפים קובץ בשם lint_pr_title.yml לספרייה .github/workflows עם התוכן הבא:
name: "Lint Pull Request Title"
on:
pull_request_target:
types:
- opened
- edited
- synchronize
jobs:
main:
name: Validate PR title
runs-on: ubuntu-latest
steps:
- uses: amannn/action-semantic-pull-request@v5
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
permissions:
pull-requests:
read statuses: write
שליחת השינויים ל-GitHub
לבסוף, משתמשים בפקודות הבאות כדי לשמור את השינויים האלה ב-GitHub Actions ולדחוף אותם ל-GitHub:
git add .github/workflows/
git commit -m "chore: Added github actions"
git push
הגנה על ההסתעפות main
בממשק המשתמש של GitHub, צריך להפעיל הגנה על ההסתעפות main כדי שמפתחים רגילים לא יוכלו לדחוף שינויים ישירות להסתעפות הזו. במקום זאת, הם מבצעים שינויים בהסתעפות אחרת ואז פותחים בקשת משיכה. מפתח אחר יכול לבדוק את בקשת המשיכה לפני שהיא מאושרת וממוזגת עם main.
כדי להגדיר הגנה על הסתעפות, עוברים לממשק המשתמש של GitHub למאגר, בוחרים באפשרות Settings ואז באפשרות Branches, ולוחצים על הכפתור Add branch protection rule:
מזינים main בשדה Branch name pattern ומסמנים את האפשרויות הבאות:
- דרישה לשליחת בקשת מיזוג לפני המיזוג
- דרישת אישורים
- דחיית אישורים של בקשות משיכה לא פעילות כשדוחפים קומיטים חדשים
לבסוף, לוחצים על הלחצן יצירה בתחתית הדף.
כשיוצרים בקשת משיכה, פעולות GitHub שהוגדרו קודם בהוראות האלה יופעלו. אחרי שהם מופעלים בפעם הראשונה, אפשר גם לבחור אותם בממשק המשתמש הזה כדי שהם יצליחו לפני שניתן יהיה למזג את בקשת המשיכה אל main.
הגדרת בקשות משיכה
ב-Looker אפשר לדרוש שימוש בבקשות משיכה ולגרום ל-Looker לפתוח בקשות משיכה בשם המפתח. ההגדרה הזו צריכה להתבצע רק במופע הפיתוח. מופע QA ומופע ייצור ישתמשו במצב פריסה מתקדם כדי לקבל את העדכונים שלהם.
כדי להפעיל את ההגדרה הזו, עוברים אל דף הגדרות הפרויקט של כל פרויקט, ואז בוחרים באפשרות Pull Requests Required (חובה לשלוח בקשות משיכה) בכותרת GitHub Integration (שילוב עם GitHub).
לוחצים על הכפתור כדי להגדיר סוד של webhook, מעתיקים את המחרוזת האקראית שנוצרת ולוחצים על הכפתור שמירת הגדרות הפרויקט.
בממשק המשתמש של GitHub למאגר, בוחרים באפשרות Settings (הגדרות) ואז באפשרות Webhooks (ווּבְהוּקים). לוחצים על הלחצן Add webhook (הוספת webhook) בפינה השמאלית העליונה:
- בשדה Payload URL (כתובת ה-URL של מטען הייעודי) מזינים
https://LOOKER_HOST_NAME/webhooks/projects/PROJECT_NAME/deploy. - בשדה Secret, מדביקים את הסוד ששמרתם מ-Looker.
- בשדה Which events would you like to trigger this webhook? (אילו אירועים יפעילו את ה-webhook הזה?), בוחרים באפשרות Let me select individual events (אני רוצה לבחור אירועים ספציפיים).
מוודאים שהאפשרויות בקשות משיכה ודחיפות מסומנות:
לבסוף, לוחצים על הלחצן הוספת webhook בתחתית הדף.
שלבי ההגדרה לכל מפתח Looker
צריך לבצע את כל שלבי ההתקנה הבאים בסביבת Linux.
התקנת Ruby
כדי להריץ את Gazer, צריך להתקין את שפת התכנות Ruby. כל גרסה של Ruby אחרי 2.7.7 תפעל עם Gazer, אבל מומלץ להשתמש ב-Ruby 3.x.x. כדי להתקין את Ruby ב-Ubuntu Linux, מריצים את הפקודות הבאות:
sudo apt update
sudo apt install ruby
כדי לוודא ש-Ruby מותקן בצורה תקינה, מריצים את הפקודה ruby -v. אמורה להתקבל תגובה שדומה לזו:
ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux]
הפקודות האלה פועלות גם ב-Debian Linux, ב-Linux Mint ובכמה גרסאות אחרות של Linux שמשתמשות במנהל החבילות Aptitude. יכול להיות שתצטרכו לחפש פקודות שפועלות בגרסאות אחרות של Linux, או פקודות להתקנה ב-macOS. מידע נוסף זמין במאמר בנושא התקנת Ruby.
התקנת Gazer
Gazer הוא פרויקט קוד פתוח שנוצר על ידי עובדי Google כדי לנווט במרחבים, בתצוגות ובמרכזי בקרה ולנהל אותם באמצעות כלי לשורת פקודה.
אחרי שמתקינים את Ruby, אפשר להשתמש בכלי Gem של Ruby כדי להתקין את Gazer:
gem install gazer
מוודאים ש-Gazer מותקן באמצעות הפקודה gzr version. אמורה להתקבל תגובה שדומה לזו:
v0.3.12
הגדרת אינטגרציה רציפה (CI) ב-Looker
כדי לבדוק ולאמת את LookML, משתמשים באינטגרציה רציפה של Looker. אינטגרציה רציפה (CI) מוטמעת ב-Looker ולא נדרשת התקנה מקומית של CLI.
כדי להשתמש בשילוב רציף:
- מוודאים שהמופע עומד בדרישות של שילוב רציף.
- מבקשים מאדמין ב-Looker להפעיל אינטגרציה רציפה ולהתקין את אפליקציית CI GitHub.
- יוצרים חבילת אינטגרציה רציפה כדי להגדיר את כלי האימות והטריגרים לפרויקט.
מידע נוסף זמין במאמרי העזרה בנושא שילוב רציף של Looker.
התקנת Git
אפשר להתקין את תוכנת ניהול הגרסאות Git ב-Ubuntu Linux באמצעות הפקודה הבאה:
sudo apt update
sudo apt install git
כדי לוודא שההתקנה הצליחה, מריצים את הפקודה git --version. אמורה להתקבל תגובה שדומה לזו:
git version 2.42.0.609.gbb76f46606
הפקודות האלה פועלות גם ב-Debian Linux, ב-Linux Mint ובכמה גרסאות אחרות של Linux שמשתמשות במנהל החבילות Aptitude. יכול להיות שתצטרכו לחפש פקודות שפועלות בגרסאות אחרות של Linux. לדוגמה, הוראות ל-Fedora ול-macOS זמינות במאמר Getting Started - Installing Git.
הגדרת Git
צריך להגדיר את Git בסביבת Linux כדי שיוכל לפעול עם מאגר Git שבו מאוחסן קובץ ה-LookML. ההוראות האלה רלוונטיות למאגרי LookML Git שמאוחסנים ב-GitHub.
שם ואימייל
ב-GitHub (וברוב ההטמעות האחרות של Git) צריך לדעת את השם וכתובת האימייל שלכם כדי שיהיה אפשר לתעד את הפעילות. מגדירים את השם וכתובת האימייל ב-Git באמצעות הפקודות הבאות:
git config --global user.name "FIRST_NAME LAST_NAME"
git config --global user.email "EMAIL_ADDRESS"
פרטי כניסה ל-Git
במהלך ההגדרה הראשונית של CI/CD נוצרו פרטי כניסה ל-git. צריך להגדיר את מפתח ה-SSH הפרטי שנוצר בקובץ $HOME/.ssh/config. כדי ליצור את הקובץ, משתמשים בפקודות הבאות:
touch $HOME/.ssh/config
chmod 600 $HOME/.ssh/config
מוסיפים את הטקסט הבא לקובץ $HOME/.ssh/config:
Host github.com
User git
IdentityFile ~/.ssh/KEY_NAME
ControlMaster auto
ControlPath ~/.ssh/ctrl-%r@%h:%p
ControlPersist yes
במקום KEY_NAME, משתמשים בשם של קובץ המפתח הפרטי שיצרתם באמצעות ההוראות שבמאמר הוספת מפתח SSH חדש לחשבון GitHub. שם הקובץ של המפתח הפרטי זהה לשם הקובץ של המפתח הציבורי, אבל בלי הסיומת .pub. לדוגמה, אם השתמשתם במפתח הציבורי שנמצא בקובץ id_ed25519.pub, המפתח הפרטי ייקרא id_ed25519.
הגדרת מאגר Git מקומי
אחרי שמגדירים את מאגר LookML, צריך ליצור ממנו עותק בסביבת Linux. כדי לעשות את זה, מריצים את הפקודה הבאה:
git clone GIT_URL
לדוגמה, הפקודה יכולה להופיע כך:
git clone git@github.com:my_org_name/sales_project.git
מאגר LookML יועתק לספריית משנה, למשל sales_project. משתמשים בפקודה cd SUB_DIRECTORY כדי להיכנס למאגר. בדוגמה הזו, הפקודה תהיה cd sales_project.
אחרי שנכנסים לספרייה של המאגר, אפשר להשתמש בפקודות הבאות:
| פקודה | מטרה |
|---|---|
git checkout BRANCH_NAME |
משמש למעבר בין ענפים. ברוב המקרים, הענף הראשי נקרא main, אבל במערכות ישנות יותר הוא נקרא master. |
git fetch |
משמש לאחזור השינויים האחרונים מהשרת. |
git pull |
משמש להחלת שינויים על קבצים מקומיים שהוצאו. git pull מבצע באופן מרומז git fetch. |
git tag |
משמש ליצירת תג בעל משמעות לגרסה מסוימת. |
git push |
משמש להעברת שינויים מקומיים לשרת. |
הגדרת Gazer
כדי להשתמש ב-Gazer, תצטרכו פרטי כניסה ל-API לכל אחד מהמופעים של הפיתוח, בקרת האיכות והייצור. הוראות ליצירת פרטי כניסה ל-API מופיעות בדף הגדרות אדמין – משתמשים. יכול להיות שהאדם שהגדיר את תהליך העבודה של CI/CD כבר יצר את פרטי הכניסה ל-API. במקרה כזה, אפשר להשתמש בפרטי הכניסה הקיימים, ולא צריך ליצור פרטי כניסה חדשים לכל אדם.
מאחסנים את פרטי הכניסה ל-API בקובץ .netrc עם הרשאות מינימליות בספריית הבית. אפשר ליצור קובץ ריק עם ההרשאות הנכונות באמצעות הפקודות הבאות:
touch $HOME/.netrc
chmod 600 $HOME/.netrc
מוסיפים לקובץ רשומות כמו אלה שבהמשך, אבל משתמשים בשמות המארחים של שרת Looker שלכם במקום machine, ובמקום client_id ו-client_secret משתמשים בפרטי הכניסה ל-API. לדוגמה:
machine dev.example.looker.com
login 80ka7nl6lj87ftmn
password u7kw3mj5h2trfz0
machine qa.example.looker.com
login fi3qtv5at5crvd1q
password bdxtaeghnzyz0wm
machine example.looker.com
login k7lr6yv57wvzy9p2
password wcvr5qjd2isbs2s
כדי לבדוק שהפעולה הזו עובדת, מריצים פקודת Gazer מול כל שרת, כמו הפקודה הבאה:
gzr user me --host dev.example.looker.com
התוצאה אמורה להיות דומה לזו:
+----+---------------+---------+----------+------------------+--------------+
| id|email |last_name|first_name|personal_folder_id|home_folder_id|
+----+---------------+---------+----------+------------------+--------------+
|2345|jsm@example.com|Smith |John | 2161| 708|
+----+---------------+---------+----------+------------------+--------------+
אם הפקודה הקודמת לא פועלת, יכול להיות שצריך להוסיף --port 443 לסוף הפקודה gzr, באופן הבא:
gzr user me --host dev.example.looker.com --port 443
הגדרת חבילות של אינטגרציה רציפה (CI)
יוצרים חבילות של שילוב רציף ב-Looker כדי לציין את כללי האימות והגדרות הבדיקה.
ב-CI suite, אפשר להגדיר את האפשרויות הבאות:
- אפשרויות להפעלת הטריגר כדי להריץ אימות אוטומטי של בקשות משיכה, לפי לוח זמנים או באופן ידני מתוך Looker IDE.
- כלי לאימות SQL כדי לבדוק מאפיינים מול מסד הנתונים.
- כלי לאימות טענות להרצת בדיקות נתונים של LookML.
- כלי לאימות התוכן כדי לבדוק טבלאות Look ולוחות בקרה.
- כלי האימות של LookML כדי לבדוק את תחביר LookML.
- כלי לאימות סגנונות כדי לאכוף סטנדרטים של קידוד LookML, מוסכמות למתן שמות ושיטות מומלצות מבניות בכל הפרויקט.
הוראות להגדרת חבילות מופיעות במאמר יצירת חבילת שילוב מתמשך.