ניהול גרסאות

Magdalena Skarbińska
Magdalena Skarbińska
Demián Renzulli
Demián Renzulli
X GitHub

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

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

זמינות

ההתנהגות של ניהול הגרסאות תלויה בשאלה אם אפליקציית ה-IWA מנוהלת על ידי אדמין או מותקנת ישירות על ידי משתמש:

  • אפליקציות IWA מנוהלות: תכונות ניהול (כולל הצמדה ושדרוג לאחור מבוססי-מדיניות) זמינות מגרסה Chrome 133.
  • אפליקציות IWA לא מנוהלות (שהמשתמשים התקינו): תכונות שפונות למשתמשים (כמו בחירה ידנית של ערוץ) זמינות מגרסה Chrome 150.

תאימות של סוגי סשנים

כל הפונקציות לניהול גרסאות – כולל ערוצי עדכון והצמדת גרסה – תואמות באופן מלא לכל סוגי הסשנים ב-ChromeOS. למשל:

  • סשנים של משתמשים מנוהלים רגילים
  • גלישות מנוהלות כאורחים (MGS)
  • סביבות ייעודיות של מצב קיוסק

עדכון ערוצים

באמצעות ערוצי עדכון, מפתחים יכולים לפלח גרסאות בנייה ספציפיות של אפליקציות עבור קהלים שונים של פריסה ובדיקה. כדי להגדיר ערוצים, מוסיפים שדה אופציונלי של מערך ערוצים לכל רשומה של גרסה במניפסט של עדכון האפליקציה. שמות הערוצים האלה לא מוגבלים למילות מפתח קבועות של הפלטפורמה (כמו canary או stable), אלא הם מזהים שרירותיים שהוגדרו על ידי המפתח. הם חייבים להיות בפורמט של מחרוזות אלפאנומריות ב-ASCII באותיות קטנות (יכולות לכלול מקפים או קווים תחתונים, אבל לא רווחים). אם רשומה של גרסה לא כוללת את השדה channels, Chrome משתמש באופן מרומז בערוץ 'default' כברירת מחדל. בסופו של דבר, שם הערוץ שמוגדר במדיניות הניהול חייב להיות זהה בדיוק למחרוזת שמוגדרת במניפסט. אם יש שגיאות הקלדה או חוסר התאמה בהגדרות, לא תזוהה גרסה מתאימה, והעדכונים של הלקוחות האלה ייעצרו.

הגדרת המניפסט

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

  • מיפוי ערוצים: אם רשומה של גרסה מגדירה מערך channels, הגרסה הזו כשירה להתקנה רק בערוצים שצוינו.
  • ברירת המחדל: אם רשומה של גרסה לא כוללת את השדה channels, ‏ Chrome מניח שהגרסה שייכת לערוץ default בלבד.
  • התאמה מדויקת של מחרוזות: שמות הערוצים שצוינו בהגדרות המדיניות בצד הלקוח צריכים להיות זהים למחרוזות שמוגדרות במניפסט העדכון (ההתאמה היא תלוית-רישיות). אם אין גרסה שתואמת לשם הערוץ המטורגט, האפליקציה לא תמצא עדכונים מתאימים.

דוגמה לעדכון מניפסט

בדוגמה הבאה מוצג מניפסט עדכון שתומך בכמה ערוצי הפצה:

{
  "versions": [
    {
      "version": "0.1.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.1.0/iwa-sink.swbn",
      "channels": ["delta"]
    },
    {
      "version": "0.2.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.2.0/iwa-sink.swbn",
      "channels": ["delta", "default"]
    },
    {
      "version": "0.3.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.3.0/iwa-sink.swbn",
      "channels": ["beta", "delta"]
    },
    {
      "version": "0.4.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.4.0/iwa-sink.swbn"
    }
  ]
}

על סמך קובץ המניפסט הזה, הגרסאות הבאות זמינות לכל ערוץ מטורגט:

  • ברירת מחדל: 0.2.0,0.4.0 (שחסר בה ערוץ מפורש ומוגדרת כברירת מחדל)
  • ‫delta: 0.1.0, 0.2.0, 0.3.0
  • ‫beta: 0.3.0

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

הצמדת גרסה

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

כדי להקפיא אפליקציית אינטרנט מבודדת (IWA) בגרסת build ספציפית, אדמינים בארגון יכולים להגדיר את המאפיין pinned_version במדיניות IsolatedWebAppInstallForceList. היכולת הזו מנוהלת בעיקר באמצעות אמצעי הבקרה האינטראקטיביים בממשק המשתמש במסוף Google Admin, בחלונית הפרטים של האפליקציה, בהתאם לתהליך ההתקנה הרגיל של IWA. עם זאת, אדמינים יכולים גם לפרוס את ערכי המדיניות האלה ישירות באמצעות הגדרות JSON גולמיות. אחרי שהאדמין מצליח לטרגט מחרוזת גרסה תקינה, Chrome שולף את החבילה הספציפית הזו וחוסם את כל העדכונים האוטומטיים הבאים.

התנהגויות ומגבלות מיוחדות

  • המשכת העדכונים (ביטול ההצמדה): כדי להפעיל מחדש את העדכונים האוטומטיים, מסירים את המאפיין pinned_version או משנים את הערך שלו לגרסת יעד חדשה יותר.
  • אין שדרוג לאחור כברירת מחדל: אם מגדירים את pinned_version לגרסה נמוכה יותר מהגרסה שמותקנת כרגע, לא יופעל רולבק אלא אם מפעילים במפורש את allow_downgrades.
  • יעדי הצמדה לא זמינים: אם הגרסה pinned_version שהוגדרה חסרה בערוץ העדכון שצוין, או שהיא ישנה יותר מהגרסה המותקנת (כשהשדרוג לגרסה קודמת מושבת), Chrome ישמור את הגרסה המותקנת ויחסום עדכונים נוספים.
  • פריסות חדשות: אם אפליקציית IWA עדיין לא מותקנת במכשיר מנוהל, ולא ניתן לאחזר את הגרסה שצוינה pinned_version או שהיא חסרה במניפסט העדכון, ההתקנה של אפליקציית ה-IWA תיכשל.

שדרוג גרסה לאחור

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

אפשר לשנמך את המינוי רק אם שני התנאים הבאים מתקיימים:

  1. הערך של pinned_version הוא גרסה ישנה יותר ותקינה.
  2. הערך של allow_downgrades מוגדר במפורש כ-true.

איך שדרוג לאחור עובד

  • מנגנון ההפעלה: המערכת מעבדת את החזרה לגרסה קודמת במהלך מחזור הבדיקה הרגיל של העדכונים (שמתבצע כל 4 עד 6 שעות).
  • מה קורה בפועל: Chrome מבצע התקנה מלאה מחדש של ה-IWA באמצעות חבילת האינטרנט הישנה יותר (‎.swbn) שצוינה במניפסט העדכון.

לוגיקה של מעבר בין ערוצים

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

תרחיש א': מעבר לערוץ עם גרסאות קודמות

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

תרחיש ב': מעבר לערוץ עם גרסה זהה

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

הגדרת מדיניות ניהול

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

ייצוג של ערך המדיניות

[
  {
    "update_manifest_url": "https://awesome-kitchen-sink.glitch.me/update.json",
    "web_bundle_id": "aiv4bxauvcu3zvbu6r5yynoh4atkzqqaoeof5mwz54b4zfywcrjuoaacai",
    "channel": "beta",
    "pinned_version": "0.7.0",
    "allow_downgrades": true
  }
]

הסברים על פרמטרים של סכימה

  • ‫channel (מחרוזת, אופציונלי): מורה ל-Chrome להעריך רק גרסאות שהוקצו לערוץ הזה במניפסט העדכון. אם לא מציינים ערוץ, Chrome בודק את הערוץ 'default'.
  • ‫pinned_version (מחרוזת, אופציונלי): נועל את המכשיר באופן מפורש לגרסת המחרוזת שצוינה. עדכונים אוטומטיים ברקע ייחסמו.
  • ‫allow_downgrades (boolean, optional): Enables rollback capability. אם המדיניות מוגדרת כ-true ומשויכת ל-pinned_version ישן ותקין, Chrome יפעיל התקנה חוזרת של גרסה קודמת. אזהרה: הגדרת הפרמטר הזה לערך True תחסום את כל העדכונים הרגילים, גם אם השדה pinned_version לא יופיע.

‫IWAs לא מנוהלים (שהמשתמשים התקינו) (מ-150)

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

חבילת התקנה ──► המשתמש בוחר ערוץ ──► בדיקות אוטומטיות בערוץ שנבחר

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

כדי שאפליקציות IWA שהמשתמשים התקינו יבדקו אם יש עדכונים תקופתיים אוטומטיים ויקבלו אותם ברקע, קובץ המניפסט המקומי של אפליקציית האינטרנט (המטא-נתונים שנארזו בחבילה במיקום /.well-known/manifest.webmanifest) חייב להכיל שדה update_manifest_url תקין.

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

בחירת ערוץ באופן ידני

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

כללים חשובים בנושא מחזור חיים

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

איך בודקים פריסות מנוהלות

לאדמינים שמנהלים מכשירים דרך מסוף Admin של Chrome Enterprise או מגדירים מדיניות ישירות:

  1. עוברים לחלונית פרטי האפליקציה בקטע 'הגדרות ארגוניות'.
  2. הגדרת מאפייני תצורה כדי לבדוק הצמדה ומיקומי יעד של ערוצים. האמצעים האלה תואמים באופן מלא להפעלות רגילות של משתמשים, להפעלות מנוהלות של משתמשים זמניים (MGS) ולעמדות מידע, כך שאתם יכולים לאמת את ההתנהגויות בכל סביבות הפריסה הרלוונטיות.
  3. כדי לבדוק עדכונים באופן מקומי, עוברים אל chrome://web-app-internals בלקוח בדיקה כדי לאלץ בדיקות עדכון באופן ידני ולנתח חבילות מניפסט נכנסות.

סיכום

ארכיטקטורת האבטחה של אפליקציות אינטרנט מבודדות (IWA) נועדה לתת למפתחים כלים שימושיים, תוך שמירה על יכולת חיזוי ושליטה קפדניות בהתנהגויות של מחזור החיים של האפליקציה. בעזרת התכונות לניהול גרסאות ב-Chrome, מפתחים ואדמינים ב-IT יכולים ליצור צינורות פריסה חזקים שתואמים לתקני תאימות מחמירים וליעדים תפעוליים.

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

  • שימוש בערוצים מתקדמים: עדכון ערוצים (כמו beta, dev או חוגים מותאמים אישית) מאפשר לכם לאסוף טלמטריה ומשוב באופן הדרגתי. כך אפשר לוודא שעדכונים חשובים עוברים אימות קפדני לפני שהם מגיעים לכלל האוכלוסייה בערוץ ברירת המחדל.
  • הצמדה ליציבות: בסביבות ארגוניות מובנות מאוד או כאלה שמונעות על ידי דרישות תאימות, כדאי לנעול נקודות קצה קריטיות ל-pinned_version מאומת ומדויק כדי להגן על פעולות מפני שיבושים לא צפויים או הפרעות בתהליכי העבודה.
  • שומרים את השדרוגים לאחור למקרי חירום: חשוב להבין שהורדת גרסה היא שסתום בטיחות יעיל לתיקון בעיות, שלא היה קיים בעבר. עם זאת, מכיוון שהחזרה לגרסה קודמת מפעילה התקנה מחדש מלאה ומנקה את כל האחסון המקומי של הלקוח (IndexedDB, ‏ LocalStorage, קובצי Cookie), צריך להשתמש בה רק לתיקון בעיות אבטחה קריטיות. במקרה של תיקונים רגילים, האסטרטגיה האידיאלית היא תמיד פריסת עדכון משני שמתייחס לעתיד.
  • הבנת דגלי המדיניות: חשוב לשים לב למתגים אדמיניסטרטיביים. הפעלת allow_downgrades תעצור את כל העדכונים העתידיים, גם אם לא הוגדר פין באופן פעיל.
  • הקמת שלמות של בייט אחר בייט: כדי למנוע מצבים לא יציבים של האפליקציה כשלקוחות עוברים בין ערוצים, צריך לוודא שמספרי גרסאות זהים שנפרסו בערוצים שונים ממופים לחבילות זהות שתואמות בייט אחר בייט.

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