שימוש בניהול גרסאות ופריסה

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

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

אפשר להגדיר את Looker כך שיפעל עם ספקי Git רבים, כמו GitHub,‏ GitLab ו-Bitbucket. מידע על הגדרת Git לפרויקט Looker זמין בדף התיעוד בנושא הגדרה ובדיקה של חיבור Git.

עבודה עם הסתעפויות של Git

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

תכונה חשובה נוספת של Git היא הקלות שבה אפשר לשתף פעולה עם מפתחים אחרים. אפשר ליצור ענף ולבצע בו שינויים (אם רוצים), ואז מפתחים אחרים יכולים לעבור לענף הזה כדי לבדוק אותו או לבצע בו שינויים. אם מפתח אחר ביצע שינויים בענף, Looker מציג את הלחצן Pull Remote Changes (שליפת שינויים מרחוק). לפני שמבצעים שינויים נוספים, צריך למשוך את השינויים המחויבים האלה אל הענף.

אפשר גם למחוק ענף שאינו הענף הראשי, הענף הנוכחי או ענף אישי של מפתח.

ענפים אישיים

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

הסניף האישי שלכם מתחיל ב-dev- וכולל את השם שלכם.

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

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

יצירת הסתעפות חדשה ב-Git

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

עם זאת, יכול להיות שתרצו ליצור ענפים חדשים של Git בנוסף לענף האישי שלכם. הוספת הסתעפות Git חדשה מתאימה למצבים הבאים:

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

לפני שיוצרים הסתעפות חדשה:

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

כדי ליצור ענף Git חדש:

1. מוודאים שמצב הפיתוח מופעל.

2. עוברים לקובצי הפרויקט בתפריט פיתוח.

   

3. בתפריט הסמלים שמימין, לוחצים על סמל Git כדי לפתוח את החלונית Git Actions (פעולות Git).

4. לוחצים על התפריט הנפתח הצגת ענפים.

5. בוחרים באפשרות ענף חדש.

   

6. בחלון New Branch (ענף חדש), מזינים שם לענף. חשוב לזכור שיש מגבלות על שמות של הסתעפויות Git. כדי לראות את הדרישות לשמות, אפשר לעיין בקטע כללים למתן שמות להסתעפויות Git בדף הזה.

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

8. לוחצים על יצירה כדי ליצור את הענף.

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

כללים למתן שמות לענף Git

‫Looker משתמש בדרישות של מוסכמות מתן שמות לענפים שצוינו על ידי Git.

שמות של ענפים ב-Git לא יכולים:

• להכיל תו רווח
• כוללים נקודותיים כפולים: ..
• כולל לוכסן הפוך: \
• הכללת הרצף: @{
• לכלול סימן שאלה: ?
• כולל סוגר מרובע פותח: [
• מכיל תו בקרה של ASCII: ‏ ~ או \^ או :
• מתחילים עם נקודה: .
• מתחילים בתחילית: dev- (שמורה לענפים אישיים של מפתחי Looker)
• מסיימים בקו נטוי: /
• סיום השיחה והפעלת התוסף: .lock

בנוסף, שם הענף יכול להכיל כוכבית (*) רק אם הכוכבית מייצגת רכיב נתיב שלם (לדוגמה, foo/* או bar/*/baz). במקרה כזה, הכוכבית מפורשת כתו כללי ולא כחלק משם הענף בפועל.

מעבר לענף אחר ב-Git

הערות:

• אם יש לכם בעיית מיזוג בענף הנוכחי, אתם צריכים לפתור את הבעיה לפני שתוכלו לעבור לענף אחר.
• אם יש לכם שינויים שלא בוצעו ב-branch הנוכחי, לא תוכלו לעבור ל-branch קיים עד שתבצעו commit של השינויים ב-branch הנוכחי.

כדי לעבור לענף Git אחר, פועלים לפי השלבים הבאים:

טיפ: אם אתם משתמשים בתוסף Looker ל-VS Code, מעבר בין ענפים באופן מקומי באמצעות git checkout יסנכרן אוטומטית את סשן הענף שלכם בשרת Looker.

1. בפרויקט, לוחצים על סמל Git בתפריט הסמלים שמימין כדי לעבור לחלונית Git Actions.
2. בחלונית Git Actions, לוחצים על התפריט הנפתח של ענף Git משמאל לשם הנוכחי של ענף Git.
3. בוחרים את הענף שאליו רוצים לעבור בתפריט, או מקלידים את שם הענף בתיבת החיפוש. החיפוש של שמות הסניפים הוא לא תלוי אותיות רישיות. לדוגמה, אם מחפשים את המחרוזת DEV, יוצגו כל הענפים שהשמות שלהם כוללים את המחרוזות dev,‏ DEV,‏ Dev וכן הלאה.

ניהול הסתעפויות ב-Git

בכרטיסייה Branch Management של הגדרות הפרויקט מוצגת טבלה עם כל ענפי ה-Git של פרויקט Looker. כדי לפתוח את הכרטיסייה Branch Management (ניהול הסניפים), קודם עוברים להגדרות הפרויקט על ידי לחיצה על סמל ההגדרות בתפריט הסמלים הימני. לאחר מכן, בוחרים בכרטיסייה ניהול סניפים.

בכרטיסייה ניהול סניפים אפשר:

1. כדי ליצור ענף חדש, לוחצים על הלחצן New Branch (ענף חדש). מידע נוסף זמין בקטע יצירת ענף Git חדש בדף הזה.
2. מחפשים שמות של סניפים בסרגל החיפוש.
3. לוחצים על הלחצן רענון כדי לרענן את הטבלה.
4. כדי למיין את הטבלה, לוחצים על שם של עמודה.

הטבלה כוללת את הפרטים הבאים:

• שם: השם של הענף ב-Git. הענפים האישיים של מפתחי Looker מתחילים ב-dev- וכוללים את השם הפרטי ושם המשפחה של המפתח.
• סטטוס: ההבדל בין הגרסה המקומית של הענף לבין הגרסה המרוחקת של הענף. לדוגמה, סטטוס של 3 commits behind מציין שהגרסה המקומית של ההסתעפות מפגרת אחרי הגרסה המרוחקת של ההסתעפות בשלושה שמירות. מכיוון ש-Looker תמיד משתמש בגרסה המרוחקת של הענף הראשי, בכרטיסייה Branch Management לא מוצג הסטטוס של הגרסה המקומית של הענף הראשי. אפשר תמיד להניח שהענף הראשי מעודכן.
• עדכון אחרון: משך הזמן שעבר מאז שמפתח Looker ביצע commit לענף.
• פעולות: לחצן למחיקת הענף או הסיבה לכך שהענף לא עומד בדרישות למחיקה.

מחיקת הסתעפויות Git

בכרטיסייה Branch Management (ניהול הסניפים), אפשר למחוק סניפים שיש להם לחצן Delete (מחיקה) בטבלה. אי אפשר למחוק את הענפים הבאים:

• הענף הראשי
• הפיצול הנוכחי לשיחה הנוספת
• ענף אישי של מפתח Looker

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

הערה: אי אפשר לשחזר ענף אחרי שהוא נמחק. כשמוחקים ענף, Looker מסיר גם את הגרסה המקומית של הענף וגם את הגרסה המרוחקת של הענף.

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

כדי למחוק ענף אחד או יותר של Git מהפרויקט, קודם עוברים להגדרות הפרויקט על ידי לחיצה על סמל ההגדרות בתפריט הסמלים הימני. לאחר מכן לוחצים על הכרטיסייה ניהול סניפים. בכרטיסייה Branch Management (ניהול הסתעפויות), אפשר למחוק הסתעפויות בשתי דרכים:

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

הפעלת פקודות Git ב-Looker

ל-Looker יש ממשק מובנה שמשולב עם שירות Git. ‫Looker מציג את לחצן Git בפינה השמאלית העליונה של סביבת הפיתוח המשולבת (IDE) של LookML.

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

אם הענף של המפתחים מסונכרן עם ענף הייצור, לחצן Git מציג את ההודעה Up to Date ואי אפשר לבחור בו.

אחרי הגדרת הפרויקט ל-Git, אפשר ללחוץ על הלחצן Git Actions (פעולות Git) כדי לפתוח את החלונית Git Actions (פעולות Git).

הפקודות שזמינות בחלונית Git Actions תלויות בשלב שבו אתם נמצאים בתהליך של ביצוע שינויים ופריסה בסביבת הייצור.

העברת השינויים לסביבת הייצור

בשילוב ברירת המחדל של Git ב-Looker, המערכת מציגה למפתחים את תהליך העבודה הבא ב-Git:

• ביצוע שינויים בענף הפיתוח הנוכחי של המפתח (והפעלת בדיקות נתונים אם הפרויקט מוגדר לדרוש בדיקות לפני הפריסה)
• מיזוג הסתעפות הפיתוח עם הסתעפות הייצור, שנקראת כברירת מחדל master
• פריסת הענף של סביבת הייצור בסביבת הייצור של Looker שתוצג למשתמשי הקצה של Looker

כלומר, בשילוב Git שמוגדר כברירת מחדל, כל המפתחים ממזגים את השינויים שלהם לתוך הסתעפות שנקראת master, וההתחייבות האחרונה בהסתעפות master היא מה שמשמש לסביבת הייצור של Looker.

במקרים של הטמעות מתקדמות של Git, אפשר להתאים אישית את תהליך העבודה הזה:

• אתם יכולים לבקש מהמפתחים לשלוח בקשות משיכה (pull requests) עבור הסתעפות הייצור של Git, במקום לאפשר להם למזג את השינויים שלהם דרך Looker IDE. פרטים נוספים זמינים בדף התיעוד בנושא הגדרת ניהול גרסאות של פרויקטים.
• אתם יכולים להשתמש בשדה שם ענף הייצור של Git כדי לציין איזה ענף ממאגר Git שלכם Looker צריך להשתמש בו כענף היעד שאליו ימוזגו הענפים של מפתחי Looker. פרטים נוספים זמינים בדף התיעוד בנושא הגדרת ניהול גרסאות של פרויקטים.
• אתם יכולים להשתמש במצב פריסה מתקדם כדי לציין שם תג או SHA של קומיט אחר לפריסה בסביבת הייצור של Looker, במקום להשתמש בקומיט האחרון בענף הייצור. (אם רוצים לפרוס שמירה מענף אחר, אפשר להשתמש במצב פריסה מתקדם webhook או נקודת קצה ל-API). פרטים נוספים זמינים בדף התיעוד בנושא מצב פריסה מתקדם.

הערה: אם במקום האפשרויות שמתוארות בקטע הזה מופיע לחצן Configure Git, צריך קודם להגדיר את Git לפרויקט.

צפייה בשינויים שלא נשמרו

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

כדי לראות סיכום של ההבדלים בין כל הקבצים, בוחרים באפשרות View Uncommitted Changes (הצגת שינויים שלא נשמרו) בחלונית Git Actions (פעולות Git).

בחלון Uncommitted Changes to Project (שינויים בפרויקט שלא נשמרו), מוצג סיכום של כל השינויים שנשמרו בכל הקבצים של הפרויקט, אבל לא נשמרו במאגר. לכל שינוי, Looker מציג את הפרטים הבאים:

• השם של הקובץ שהוחלף והשם של הקובץ שנוסף.
  • השם של הקובץ שהוחלף (מסומן ב----) והשם של הקובץ שנוסף (מסומן ב-+++). במקרים רבים, יכול להיות שיוצגו גרסאות שונות של אותו קובץ, עם מספרי תיקונים שמסומנים ב---- a/ וב-+++ b/.
  • קבצים שנמחקו מוצגים כהחלפה של קובץ null ‏ (+++ /dev/null).
  • הקבצים שנוספו מוצגים כהחלפה של קובץ null ‏ (--- /dev/null).
• מספר השורה שבה מתחיל השינוי.
  לדוגמה, -101,4 +101,4 מציין שבשורה 101 בקובץ, 4 שורות הוסרו ו-4 שורות נוספו. אם קובץ שנמחק מכיל 20 שורות, יופיע בו הערך -1,20 +0,0 כדי לציין שבשורה הראשונה בקובץ הוסרו 20 שורות והוחלפו באפס שורות.
• הטקסט שעודכן:
  • שורות שנמחקו מוצגות באדום.
  • שורות שנוספו מוצגות בירוק.

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

ביצוע השינויים

אחרי שמבצעים שינויים בפרויקט של LookML ושומרים אותם, יכול להיות שיהיה צורך לאמת את ה-LookML ב-IDE. במקרה כזה, הכפתור Git מציג את הטקסט Validate LookML.

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

אם מפתח אחר ביצע שינויים בענף הייצור מאז העדכון האחרון של הענף המקומי, Looker יחייב אתכם למשוך את העדכונים האלה מענף הייצור. במקרה כזה, הלחצן Git יציג את הטקסט Pull from Production.

הערה: אם הפרויקט מוגדר למצב פריסה מתקדם, במקום לחצן Git מוצג הטקסט Pull from Primary Branch (שליפה מהענף הראשי).

אחרי ששומרים את השינויים (ומתקנים אזהרות או שגיאות ב-LookML, אם צריך) ומבצעים משיכה מהייצור (אם צריך), הלחצן Git מציג את הטקסט Commit Changes & Push (שמירת השינויים ודחיפה).

אם רוצים, אפשר קודם לבדוק את השינויים שלא נשמרו לפני ששומרים אותם.

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

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

בדיקה של PDTs שלא נוצרו

אם ביצעתם שינויים ב-PDT כלשהם בפרויקט, מומלץ לבנות את כל ה-PDT כשמבצעים פריסה בסביבת הייצור, כדי שאפשר יהיה להשתמש בטבלאות באופן מיידי כגרסאות הייצור. כדי לבדוק את הסטטוס של PDT בפרויקט, לוחצים על הסמל Project Health כדי לפתוח את החלונית Project Health, ואז לוחצים על הלחצן Validate PDT Status.

מידע נוסף על בדיקה של PDT שלא נבנו בפרויקט של LookML ועל עבודה עם טבלאות נגזרות במצב פיתוח זמין בדף התיעוד בנושא טבלאות נגזרות ב-Looker.

הפעלת בדיקות נתונים

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

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

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

1. אם הגדרתם את הגדרות הפרויקט כך שנדרש לעבור בדיקות נתונים לפני פריסת הקבצים בסביבת הייצור, אחרי שתבצעו commit של השינויים בפרויקט, סביבת ה-IDE תציג את הלחצן הפעלת בדיקות כדי להפעיל את כל הבדיקות בפרויקט, בלי קשר לקובץ שבו מוגדרת הבדיקה. כדי להטמיע את השינויים בסביבת הייצור, צריך לעבור את בדיקות הנתונים.
2. לוחצים על הכפתור Run Data Tests (הפעלת בדיקות נתונים) בחלונית Project Health (תקינות הפרויקט). ‫Looker יריץ את כל בדיקות הנתונים בפרויקט, לא משנה באיזה קובץ מוגדרת הבדיקה.
3. בתפריט הקובץ, בוחרים באפשרות Run LookML Tests (הפעלת בדיקות LookML). ‫Looker יריץ רק את הבדיקות שמוגדרות בקובץ הנוכחי.

אחרי שמריצים את בדיקות הנתונים, ההתקדמות והתוצאות מוצגות בחלונית Project Health.

• בדיקת נתונים עוברת בהצלחה אם הטענה של הבדיקה נכונה לגבי כל שורה בשאילתה של הבדיקה. פרטים על הגדרת טענות ושאילתות לבדיקה מופיעים בדף התיעוד של הפרמטר test.
• אם בדיקת הנתונים נכשלת, בחלונית Project Health יופיע מידע על הסיבה לכשל בבדיקה, על כך שהבדיקה מצאה שגיאות בלוגיקה של המודל או על כך שהבדיקה עצמה לא הייתה תקפה.
• מתוצאות בדיקת הנתונים, אפשר לבחור את השם של בדיקת הנתונים כדי לעבור ישירות אל LookML של בדיקת הנתונים, או לבחור את הלחצן Explore Query כדי לפתוח את Explore עם השאילתה שהוגדרה בבדיקת הנתונים.

פריסה בסביבת ייצור

אחרי שמבצעים שינויים בהסתעפות, סביבת הפיתוח המשולבת של Looker תציג בקשה למזג את השינויים עם ההסתעפות הראשית. סוג ההנחיה שיוצג בסביבת הפיתוח המשולבת (IDE) תלוי בהגדרות הפרויקט:

• אם הפרויקט מוגדר למצב פריסה מתקדם, סביבת הפיתוח המשולבת תציג בקשה למזג את השינויים עם הענף הראשי. אחרי שמאחדים את הקומיט, מפתח Looker עם הרשאת deploy יכול לפרוס את הקומיט בסביבת הייצור באמצעות כלי הפריסה של Looker IDE, או באמצעות webhook או נקודת קצה ל-API.
• אם הפרויקט מוגדר לשילוב עם Git באמצעות בקשות משיכה, תופיע בקשה לפתוח בקשת משיכה באמצעות הממשק של ספק Git.
• אחרת, בשילוב ברירת המחדל של Looker עם Git, אם יש לכם הרשאה מסוג deploy, סביבת הפיתוח המשולבת (IDE) של Looker תציג לכם בקשה למזג את השינויים עם ענף הייצור ולפרוס את השינויים בגרסת הייצור של מופע Looker.

ביטול הנעילה של ענף Git נעול

גרסת טרום-GA: השימוש בתכונה הזו כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, בחלק תנאים כלליים לשירות של התנאים הספציפיים לשירות. השימוש בתכונות ובמוצרים בגרסת טרום-GA הוא "כפי שהם" (As is), ויכול להיות שהתמיכה בהם תהיה מוגבלת. מידע נוסף זמין בקטע תיאורים של שלבי ההשקה.

אם נתקלתם בבעיה במהלך התצוגה המקדימה הציבורית של ביטול הנעילה של ענף Git, דווחו על כך לכתובת [e-mail].

עכשיו זמינה תצוגה מקדימה של אפשרות חדשה למפתחי LookML: הם יכולים לבטל את הנעילה של ענף Git במקרים שבהם הענף ננעל כתוצאה מפעולת Git אחרת שנמצאת בתהליך או מפעולת Git קודמת שנכשלה. כשמאגר Git נעול, האפשרות ביטול הנעילה של הענף מוצגת ב-Looker בחלונית פעולות Git של Looker IDE. בנוסף, אם מפתח LookML ינסה לבצע קומיט של שינוי בענף Git נעול, תוצג אזהרה בתיבת הדו-שיח Commit ב-Looker, יחד עם אפשרות למחוק את הנעילה של Git.

מחיקת עותק המפתח של פרויקט LookML

גרסת טרום-GA: השימוש בתכונה הזו כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, בחלק תנאים כלליים לשירות של התנאים הספציפיים לשירות. השימוש בתכונות ובמוצרים בגרסת טרום-GA הוא "כפי שהם" (As is), ויכול להיות שהתמיכה בהם תהיה מוגבלת. מידע נוסף זמין בקטע תיאורים של שלבי ההשקה.

אם נתקלתם בבעיה במהלך התצוגה המקדימה הציבורית של מחיקת עותק הפיתוח, אתם יכולים לדווח עליה לכתובת [e-mail].

בפעם הראשונה שפותחים פרויקט LookML במצב פיתוח, סביבת הפיתוח המשולבת (IDE) של Looker מציגה את הגרסה של הפרויקט במצב ייצור, יחד עם הלחצן יצירת עותק למפתחים. כשלוחצים על הלחצן יצירת עותק למפתחים של הפרויקט, Looker יוצר שיבוט מקומי של מאגר ה-Git של הפרויקט, יוצר ענף Git אישי וטוען את פרויקט LookML במצב פיתוח.

אם אתם לא צריכים את העותק המקומי של מאגר Git למפתחים, אם אתם נמצאים במצב Git לא עקבי או אם אתם לא מצליחים לערוך את קובצי LookML, אתם יכולים למחוק את העותק למפתחים כמו שמתואר בקטע הזה.

אם תמחקו את עותק המפתחים של מאגר ה-Git של הפרויקט, תאבדו את הדברים הבאים:

• כל השינויים שלא ביצעתם להם קומיט ודחפתם אותם למאגר המרוחק
• כל ענף Git שיצרתם, אם עדיין לא ביצעתם commit ו-push של שינוי בענף הזה

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

כדי למחוק את העותק למפתחים של מאגר הפרויקט LookML:

1. פותחים את פרויקט LookML בסביבת הפיתוח המשולבת (IDE) של Looker.
2. לוחצים על סמל ההגדרות בתפריט הסמלים של Looker IDE כדי להציג את הגדרות הפרויקט. הכרטיסייה הגדרה נפתחת כברירת מחדל.
3. בכרטיסייה Configuration, לוחצים על הלחצן Delete Developer Copy.
4. כדי למנוע מחיקה בטעות של עותק הפיתוח של מאגר הפרויקט, Looker מציג תיבת דו-שיח לאישור. בתיבת הדו-שיח לאישור, מזינים את השם של פרויקט LookML בשדה הטקסט.
5. כדי למנוע מחיקה בטעות של עותק הפיתוח של מאגר הפרויקט, Looker מציג תיבת דו-שיח לאישור. בתיבת הדו-שיח לאישור, מזינים את השם של פרויקט LookML בשדה הטקסט.
6. לוחצים על הלחצן מחיקת עותק למפתחים של <שם הפרויקט שלך>.

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

אם רוצים ליצור עותק חדש למפתחים של מאגר הפרויקט, לוחצים על הלחצן יצירת עותק למפתחים.

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

באינטגרציה של Looker עם Git שמוגדרת כברירת מחדל, מפתחי Looker מבצעים קומיט של השינויים שלהם בהסתעפות הפיתוח, ואז ממזגים את הסתעפות הפיתוח עם הסתעפות הייצור. לאחר מכן, כשפורסים בסביבת Looker, מערכת Looker משתמשת ב-commit האחרון בענף הייצור. (בקטע העברת השינויים לסביבת הייצור בדף הזה מוסבר על תהליך העבודה של Git כברירת מחדל ועל אפשרויות אחרות להטמעות מתקדמות של Git).

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

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

• שימוש בכלי הפריסה בסביבת הפיתוח המשולבת (IDE) של Looker
• הפעלת webhook

• באמצעות נקודת קצה ל-API

  הערה: בפרויקטים שמופעל בהם מצב פריסה מתקדם, אם הפרויקט מעולם לא נפרס בסביבת ייצור, הפריסה הראשונית בסביבת הייצור חייבת להתבצע באמצעות כלי הפריסה בסביבת הפיתוח המשולבת (IDE) של Looker. אי אפשר להשתמש ב-API או ב-webhook לפריסה הראשונית של פרויקט שמשתמש במצב פריסה מתקדם. אחרי הפריסה הראשונית בסביבת הייצור (גם אם הפריסה הראשונית בוצעה בלי מצב פריסה מתקדם), אפשר להשתמש ב-webhook או ב-API כדי לפרוס שינויים נוספים בסביבת הייצור באמצעות מצב פריסה מתקדם.

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

בדיקת ההשפעה של השינויים

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

טיפול בבעיות אופייניות

במהלך העבודה על המודל, יכול להיות שתצטרכו לבצע אחת מהפעולות הבאות:

• מחיקת השינויים

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

• איך לטפל בהתנגשויות מיזוג עם עבודה של מפתחים אחרים

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

• פתרון השגיאה Pull Remote Changes Failed. Pull Incomplete

  אם מופיעה השגיאה Pull Remote Changes Failed. Pull Incomplete, בדרך כלל המשמעות היא שיש התנגשות בין השינויים המקומיים לבין המאגר המרוחק ש-Git לא יכול לפתור באופן אוטומטי. כדי לפתור את השגיאה הזו, צריך לשמור את השינויים המקומיים באופן ידני ואז למחוק את העותק למפתחים.

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

חזרה לשינויים שלא בוצעו

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

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

• כשמשנים את השם של קובץ, בעצם מוחקים את הקובץ המקורי ויוצרים קובץ חדש עם שם חדש. מכיוון שמדובר ביותר מקובץ אחד, אי אפשר להשתמש באפשרות החזרת קובץ למצב הקודם כדי לבטל את שינוי השם של קובץ. אם רוצים לבטל שינוי שם של קובץ, משתמשים באפשרות חזרה ל... בחלונית פעולות Git.
• כשמוחקים קובץ, הוא לא מוצג יותר בדפדפן הקבצים של סביבת הפיתוח המשולבת. אם רוצים לבטל את המחיקה של קובץ, משתמשים באפשרות Revert to…‎ (חזרה אל…) בחלונית Git Actions (פעולות Git).

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

1. בחלונית Git Actions (פעולות Git), בוחרים באפשרות Revert to... (חזרה לגרסה...).
2. בוחרים אפשרות להחזרה:
   • כדי לבטל רק שינויים שלא נשמרו, בוחרים באפשרות ביטול שינויים שלא נשמרו. אפשר גם ללחוץ על הקישור הצגת השינויים כדי לראות את השינויים שיבוטלו.
   • כדי לבטל את כל השינויים, כולל שינויים שלא בוצעו ושינויים שבוצעו, בוחרים באפשרות חזרה לגרסת הייצור.
3. כדי להשלים את תהליך החזרה לגרסה הקודמת, לוחצים על אישור.

כדי לבטל את כל התוספות או המחיקות בתוכן של קובץ יחיד, בוחרים באפשרות ביטול השינויים בתפריט של הקובץ:

פתרון בעיות שנובעות ממיזוג

בדרך כלל, Git יכול למזג אוטומטית את השינויים החדשים עם גרסת הייצור של קובצי ה-LookML. בעיית מיזוג מתרחשת כש-Git נתקל בשינויים סותרים ולא יכול לזהות אילו שינויים צריך לשמור, בדרך כלל כשמפתח אחר ביצע שינויים מאז הפעם האחרונה שמשכתם שינויים, ואתם ביצעתם שינויים באותו אזור. אם יש לכם קונפליקט במיזוג בקוד, Looker מציג אזהרה של Merge conflicts אחרי שאתם מבצעים commit לשינויים ומבצעים pull מהייצור.

כשמוצגת ב-Looker אזהרה על מיזוג עם קונפליקט, מומלץ לפתור את הקונפליקט לפני שמבצעים שינויים נוספים. אם תדחפו ל-production מיזוג שכולל קונפליקט, יתרחשו שגיאות בניתוח הנתונים, וייתכן שלא תוכלו לבצע ניתוח של הנתונים. אם אתם משתמשים מתקדמים ב-Git ורוצים להמשיך בהעלאת השינויים, לוחצים על הלחצן Don't Resolve (לא לפתור).

בקובץ LookML עצמו, השורות עם ההתנגשויות מסומנות כך:

<<<<<<< HEAD
Your code
&#61;&#61;&#61;&#61;&#61;&#61;&#61;
Production code
>>>>>>> branch 'master'

ב-Looker מוצגים סמני מיזוג כדי לציין את בעיות המיזוג:

• ‫<<<<<<< HEAD מציין את תחילת השורות שכוללות קונפליקט.
• ‫>>>>>>> branch 'master' מציין את סוף השורות שכוללות את הקונפליקט.
• התווים ======= מפרידים בין כל גרסה של הקוד כדי שתוכלו להשוות ביניהן.

בדוגמה הקודמת, your code מייצג את השינויים שביצעתם, ו-production code מייצג את הקוד ש-Git לא הצליח למזג אליו את השינויים באופן אוטומטי.

כדי לפתור בעיה של מיזוג:

1. מאתרים את הקבצים עם בעיות במיזוג. ‫Looker מסמן את הקבצים האלה באדום, או שאתם יכולים לחפש בפרויקט סמני מיזוג, כמו <<<< או HEAD, כדי למצוא את כל הקונפליקטים בפרויקט. אפשר גם למצוא את הקבצים המושפעים על ידי לחיצה על הקישור files באזהרת המיזוג שמופיעה בחלונית Git Actions.
2. בתוך הקובץ, עוברים לשורות עם בעיות במיזוג ומוחקים את גרסת הטקסט שלא רוצים לשמור, וגם את כל הסמנים של בעיות המיזוג.

3. שומרים את הקובץ וחוזרים על השלבים הקודמים לגבי כל קובץ אחר שמסומן כקובץ עם בעיות במיזוג.

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

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

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

פתרון בעיות שקשורות לכשלים בפריסה שקטה ולשינויים שלא מסונכרנים

יכול להיות שתיתקלו בהתנהגות לא צפויה ב-Looker Deployment Manager, למשל:

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

מטרה

התסמינים האלה נגרמים בדרך כלל מנעילה לא פעילה של Git או מהפניה מתנגשת (כמו תג קיים שמפנה ל-SHA ספציפי של קומיט) במאגר העורפי. הפעולה הזו מפעילה שגיאה פנימית ב-Branch already exists, שמונעת את העדכון של קובץ ה-LookML של הייצור וגורמת לפריסה להיכשל בלי להציג הודעה.

רזולוציה

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

1. ב-Looker, עוברים להגדרות של פרויקט LookML המושפע.
2. בוחרים באפשרות איפוס החיבור ל-Git.
3. מזינים מחדש את כתובת ה-URL של המאגר ולוחצים על המשך.
4. ‫Looker ייצור מפתח פריסה חדש של SSH. מוסיפים את המפתח הציבורי החדש לספק Git כמפתח פריסה למאגר.
   • חשוב לאפשר גישת כתיבה (אם משתמשים ב-GitHub) או הרשאה מקבילה אצל ספק Git.
5. לוחצים על בדיקה והשלמת ההגדרה כדי ליצור את החיבור החדש.

פתרון השגיאה Pull Remote Changes Failed. Pull Incomplete

אם מופיעה השגיאה Pull Remote Changes Failed. Pull Incomplete, אפשר לפתור אותה באחת מהדרכים הבאות:

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

פתרון השגיאה Production HTTPS credentials are OK but your development HTTPS credentials are failing to authorize to the remote

אם אתם משתמשים בפרטי כניסה של HTTPs כדי להתחבר לספק Git, יכול להיות שתופיע השגיאה Production HTTPS credentials are OK but your development HTTPS credentials are failing to authorize to the remote כשאתם מושכים שינויים מרחוק כדי לסנכרן את הגרסאות האחרונות של קבצים שהשתנו בענף מהקצה המרוחק לקבצים המקומיים.

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

כדי לפתור את השגיאה הזו, צריך ליצור אסימון חדש לגישה אישית מספק Git (לדוגמה, Azure DevOps או GitLab) ולעדכן את פרטי הכניסה לפיתוח ב-Looker באמצעות האסימון החדש שנוצר. כדי למנוע את השגיאה הזו בעתיד, כדאי לעקוב אחרי תאריך התפוגה של אסימון הגישה האישי שלכם ל-Git, ולוודא שהוא מתעדכן ב-Looker לפני שהוא פג.

מנגנון איסוף ב-Git

איסוף הזבל של Git מנקה קבצים מיותרים ודוחס גרסאות קבצים כדי לייעל את מאגר ה-Git שלך. מנגנון איסוף הזבל (git gc) של Git מופעל באופן אוטומטי כשמעדכנים או מפעילים מחדש את מופע Looker. כדי למנוע הפעלה של git gc בתדירות גבוהה מדי, Looker ממתין 30 ימים מאז הפעם האחרונה ש-git gc הופעל, ואז מפעיל את git gc בהפעלה מחדש הבאה.

במקרים נדירים, יכול להיות שתנסו להשתמש באפשרות Push Changes to Remote או באפשרות Push Branch to Remote בזמן ש-git gc פועל. אם מוצגת שגיאה ב-Looker, צריך לחכות דקה או שתיים ואז לנסות שוב להעביר את השינויים.