מהדורות עם תמיכה לטווח ארוך

עדכונים תכופים של מערכת ההפעלה חיוניים כדי לשמור על האבטחה ולקבל גישה לתכונות העדכניות ביותר. כברירת מחדל, ב-ChromeOS מתפרסם עדכון מלא של מערכת ההפעלה בערוץ היציב (Stable) בערך כל 4 שבועות. עדכונים קטנים, כמו תיקוני אבטחה ועדכוני תוכנה, מתבצעים כל שבועיים עד שלושה שבועות. מפתחים יכולים לבדוק את האפליקציות שלהם בערוץ למפתחים (Dev) או בערוץ בטא (Beta) לפני שכל גרסה יציבה חדשה יוצאת, כדי לוודא שהאפליקציות שלהם פועלות בצורה תקינה. ערוץ Dev מתעדכן פעם או פעמיים בשבוע, ומוצגות בו הפעולות שצוות Chrome עובד עליהן כרגע. יכול להיות שיהיו באוסף הזה באגים, אבל הוא מאפשר לכם לראות מראש מה צפוי להגיע לערוץ היציב בעוד 9 עד 12 שבועות. בגרסת הבטא אפשר לראות מראש את התכונות שיושקו בגרסה היציבה, 4-6 שבועות לפני ההשקה.

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

מהדורות עם תמיכה לטווח ארוך

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

ב-ChromeOS יש שתי גרסאות תמיכה לטווח ארוך: גרסת מועמד לתמיכה לטווח ארוך (LTC) וגרסת תמיכה לטווח ארוך (LTS).

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

ציר זמן של גרסאות יציבות, LTC ו-LTS

מחזור החיים של גרסאות LTC / LTS פועל באופן הבא:

• גרסת ה-LTC (108 LTC בתרשים) נגזרת מהגרסה היציבה (108 Stable), ולכן במהלך החודש הראשון הן זהות.
• החל מערוץ LTC, מתחילים לקבל תיקוני אבטחה כל שבועיים למשך 3 החודשים הבאים, עד לגרסת ה-LTS הבאה (108 LTS בתרשים). המשמעות היא ש-3 חודשים אחרי ההפצה הראשונית של LTC, ערוץ ה-LTC ישקף את ערוץ ה-LTS.
• אחרי שגרסת LTS מתפרסמת, היא ממשיכה לקבל תיקוני אבטחה כל שבועיים.
• מכשירים שנותרו בערוץ LTC אחרי שגרסת LTS מתפרסמת ימשיכו לקבל תיקוני אבטחה כל שבועיים, ויתעדכנו אוטומטית לגרסת ה-LTC הבאה כשהיא תושק.

בנוסף לתכונות של מערכת ההפעלה ולתיקוני באגים, עדכוני קושחה כלולים גם במהדורות LTS עד לסוף תקופת העדכון האוטומטי (AUE) של המכשיר.

כדי להפעיל את אחד מהערוצים, צריך דומיין Google ומכשיר מנוהל. אתם יכולים להירשם לתקופת ניסיון של Chrome Enterprise Upgrade כדי לקבל גישה למסוף Google Admin, שמאפשר לכם להגדיר ולפרוס מכשירי Chromebook מנוהלים. לבסוף, מעבירים את המכשירים המנוהלים לערוץ LTS או LTC דרך מסוף Admin. אנחנו ממליצים להשאיר את רוב המכשירים בערוץ LTS ולהשתמש ב-LTC כדי לבדוק את גרסת ה-LTS הקרובה.

תהליך בדיקה לערוץ LTC / LTS

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

• מומלץ לבצע בדיקות בערוצים Dev ובטא לפני הגרסה היציבה שתתאים לגרסה הקרובה של ערוץ ה-LTC.
• אחרי ש-LTC יושק, תצטרכו לבדוק אותו כדי לוודא שתיקוני האבטחה שהוחלו לא משפיעים על העבודה שלכם עד ש-LTS יופסק.
• אחרי ש-LTC יקודם ל-LTS, ‏ LTS ימשיך לקבל תיקוני אבטחה כל שבועיים. כדאי גם לבדוק אותם.

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

• כדאי להתחיל לבדוק בגרסה 108 Dev ובגרסה 108 Beta כדי לוודא שהכול פועל כמו שצריך לפני ההשקה של גרסה 108 Stable, שממנה תופק גרסה 108 LTC.
• בדיקה ב-108 LTC כל שבועיים עד ש-108 LTS יושק שלושה חודשים מתאריך הגרסה הראשונית.
• כדאי להמשיך לבצע בדיקות ב-LTS באופן קבוע כדי לוודא שתיקוני האבטחה לא גורמים לבעיות.

ניהול שינויים בין גרסאות LTC/LTS

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

איך מוודאים תאימות לאחור

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

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

if ('gpu' in navigator) {
  // WebGPU is supported! Accelerate computation.
} else {
  // No WebGPU, fallback to JavaScript implementation.
}

מספקים מופעים נפרדים

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

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

אפליקציית Android שמיועדת לספק גרסת תמיכה לטווח ארוך רק למשתמשי ChromeOS יכולה ליצור דף מוצר נפרד עם ההגדרות הבאות בקובץ AndroidManifest.xml כדי לציין שהיא צריכה להיות זמינה רק למכשירי ChromeOS:

<uses-feature android:name="org.chromium.arc" android:required="true" />