בכל חודש אנחנו משיקים גרסה חדשה של Chrome כדי שמיליארדי המשתמשים והעסקים שלנו ברחבי העולם יקבלו את התכונות, עדכוני האבטחה ושדרוגי הביצועים העדכניים ביותר. ועכשיו, אנחנו יכולים לבצע שיפורים ולתקן בעיות מהר יותר מתמיד עם מחזור גרסאות מהיר יותר – כלומר, העדכונים האחרונים יישלחו אליכם לעיתים קרובות יותר.
שוחחנו עם מנהלי התוכניות הטכניים בן הנרי, קרישנה גובינד, הארי סודרס, סריניוואס סיסטה וברנדון הינן בצוות ההפצה של Chrome, כדי לבחון איך הם מתאמים עם צוותי Google ברחבי העולם כדי להבטיח שכל גרסה תתבצע בצורה חלקה.
ש. איך הצוות מתכונן לכל גרסה של Chrome?
בן: ראשית, הצוות שלנו כולל שבעה אנשים שעובדים במשרה מלאה בשני אזורים גיאוגרפיים עיקריים. אנחנו חושבים שהכנה להשקה היא כמו לוח זמנים של רכבות. אנחנו משתמשים בארבעה ערוצי הפצה – Canary, Dev, בטא ויציב – כדי להתכונן לקראת ההשקה של אבני דרך ב-Chrome. ככל שאנחנו מתקדמים בתהליך, בכל ערוץ יהיו יותר משתמשי Chrome. כך אנחנו יכולים לקבל משוב לגבי היציבות והביצועים של Chrome במטרה לחשוף בעיות איכות במוצר מוקדם ככל האפשר. כדי לעזור לנו לזהות את כל מה שאנחנו מחמיצים, אנחנו בוחנים היטב את מה שמשתמשים ומפתחים אומרים ברשתות החברתיות, במאמרים בעיתונות ובדוחות על באגים. לאחר מכן, צוות המהנדסים ומנהלי המוצר שלנו יכול להשתמש במשוב הזה כדי לשפר את התכונות.
לאחר מכן אנחנו מבצעים מספר סבבי בדיקות כדי לזהות בעיות איכות, תחילה באמצעות מערכות אוטומטיות שפועלות ברציפות, ולאחר מכן עם צוותי בדיקה שמוצאים באגים באופן ידני.
ש. יש לך אפשרות לשתף דוגמה למשוב שקיבלת ממפתח חיצוני שחשוב לך לוודא ששלחת את הגרסה הכי טובה שאפשר?
Srinivas: אנחנו תמיד מסתמכים על מפתחי האתרים שלנו כדי לקבל משוב ולהתחיל להשתמש בתכונות כמו ממשקי API חדשים או שינויים במפרטים של Chrome ב-iOS. מכיוון שציון הדרך העיקרי שלנו משתנה משתי ספרות לשלוש ספרות (99 ל-100), שיתפנו הנחיות עם מפתחי אתרים כדי לבדוק דברים לפני השינוי בפועל, כדי להבטיח ששילבנו את המשוב שלהם, וחשוב מכך, לא לשבור את האתרים שלהם. כך הצלחנו להשיק את השינוי בלי בעיות חמורות בהשקה של M100.
ש. מה קורה אם מבחינים בבאג או בבעיית אבטחה במהלך ההשקה של עדכון ל-Chrome?
Krishna: אנחנו מקפידים להשיק בהדרגה גרסאות חדשות של Chrome למשתמשים. גרסאות חדשות לא נשלחות באופן מיידי ל-100% מהמשתמשים. אם נגלה באג קריטי, הפסקנו את ההפצה של הגרסאות המושפעות כדי להגביל את ההשפעות שלו. לאחר מכן אנחנו מתאמים עם צוותים של Chrome ברחבי העולם לפתח תיקון ולתקן את Chrome באופן מהיר ובטוח ככל האפשר. לאחר אימות התיקון, אנחנו יוצרים גרסה חדשה של Chrome ומתחילים שוב את תהליך ההשקה. בסופו של יום, רוב המשתמשים לא יחוו את הבעיה, כי היא תוקנה עוד לפני שהגרסה הושקה אצלם. בכל הנוגע לבעיות אבטחה, אנחנו פועלים בהתאם למדיניות בנושא Project Zero Disclosure. לכן, כשיש ניצול פעיל של נקודות חולשה ברחבי העולם, המטרה שלנו היא להפיץ את התיקון הזה למשתמשים בערוץ היציב שלנו תוך שבעה ימים.
ש. האם נדרשת עבודה נוספת כדי לוודא שגרסאות Chrome מוכנות עבור עסקים?
Brandon: אחת המטרות העיקריות שלנו היא להבטיח ש-Chrome ימשיך להיות פלטפורמה יציבה ואמינה עבור העסקים הרבים שתלויים בנו. המשמעות היא שאנחנו מעניקים לעסקים גישה לפונקציונליות הטובה והעדכנית ביותר שהם רוצים שהאנשים שלהם ינצלו, ויחד עם זאת למנוע שיבושים אפשריים בעבודה שלהם. מכיוון שהצרכים של העסק הם ייחודיים וכל זמן השבתה עלול לפגוע בארגון, ל-Chrome יש הנחיות ספציפיות לצוותי ההנדסה והמוצרים שלנו, ואנחנו בודקים כל השקה של תכונה כדי לוודא שכל הגרסאות של Chrome 'ידידותיות לארגונים'. בין היתר, אנחנו יכולים לעדכן חברות לגבי שינויים חשובים בנתוני הגרסה של Chrome Enterprise. וכדי להוסיף שקט נפשי, מנהלי IT יכולים לשלוט בשינויים רבים באמצעות מדיניות ארגונית. כך שאם הם מעדיפים לבצע בדיקות פנימיות או לבטל את ההסכמה לשימוש בתכונה חדשה, הם יכולים לעשות זאת בדיוק. כדי למנוע בעיות בלתי צפויות, יש לנו תשתית בדיקות ייעודית שנועדה לדמות סביבות ארגוניות (לדוגמה, הפעלת Chrome במכשירים המשויכים לדומיין של Active Directory), ואנחנו משתמשים בה כדי לבדוק את כל הגרסאות של Chrome.
ב-Chrome יש גם מגוון של בקרות עדכון לבתי ספר ולעסקים. אדמינים יכולים לשלוט בגרסה הספציפית של Chrome, לחזור לגרסאות ישנות יותר ולנצל את היתרונות של ערוץ הגרסה היציב המורחבת שלנו הנתמך באופן מלא. אפשר לקרוא פרטים נוספים במסמך הטכני הזה. אדמינים שרוצים לראות את סטטוס העדכון המלא של המכשירים שלהם יכולים להשתמש בדוח הגרסאות שכלול בממשק המרכזי לניהול דפדפן Chrome.
ש. האם יש שינויים שהצוות שלך מתכוון לבצע בעתיד?
הארי: אנחנו תמיד מחפשים דרכים לשפר את Chrome עבור המשתמשים והמפתחים שלנו, במיוחד כשמדובר בקיצור מחזור הגרסאות. כך המשתמשים יראו Chrome יציב יותר עם תיקוני באגים מהירים יותר ותכונות חדשות. כמו כן, אנחנו יודעים שהמהנדסים ומנהלי המוצר שלנו נהנים ממהירות פיתוח גבוהה יותר, הודות לפיתוח מהיר יותר של תכונות, למחזורי איטרציה מהירים יותר ולשמירה על תקינות הקוד. נניח שמנהל מוצר רוצה להשיק תכונה לכל משתמשי Chrome. ייתכן שיחלפו עד 16 שבועות ממועד הסיום של התכונה ועד שהיא זמינה לכלל המשתמשים. קיצור מחזור הגרסאות במספר שבועות בלבד יכול לקצר משמעותית את זמן הביצוע של השקת תכונה חדשה.