פרסום תוסף Firefox: היכן נתקעת הביקורת בקטלוג
החבילה נבנתה, נחתמה ונשלחה לבדיקה — ואחרי כמה ימים היא חוזרת בשורה אחת: «אינה עומדת במדיניות». מה בדיוק הופר לא ברור מהניסוח: ייתכן שהאוטומציה נתפסה על קוד מכווץ, וייתכן שהבודק לא ראה הצדקה להרשאות מורחבות.
מחזור השחרור נעצר: הבנייה מוכנה, אבל אי אפשר לפרסם אותה, וזמני הבדיקה בקטלוג אינם מוצהרים מראש ותלויים בתור ובסוג השינויים.
סיבות החזרת החבילה הן כמעט תמיד טכניות וצפויות מראש. הרצת קוד דינמית, חיבור סקריפטים חיצוניים, ערפול בלי קוד מקור מצורף והוראות לבנייה משוחזרת — כל אלה עילה מוכנה לסירוב.
בנפרד תופסים פער בין ההרשאות המוצהרות להתנהגות בפועל: אם התוסף מבקש גישה ללשוניות, אבל בתיאור אין על כך מילה, בדיקת התוסף תחזיר את החבילה לתיקון.
הביקורת עצמה מתנהלת בשני רבדים: בדיקות אוטומטיות לקריאות מסוכנות ובדיקה ידנית לאותן בניות שבהן צריך להעריך את משמעות ההתנהגות. כל שינוי בהרשאות או הוספה של פניות חיצוניות מעבירה את העדכון לבדיקה מורחבת, ולכן תיקון נקודתי גובה אותו זמן כמו שחרור גדול. שליחה חוזרת בלי לטפל בסיבה הראשונית מובילה לאותה תוצאה ודוחקת את התור.
מפרקים איך סוגרים את זה: בונים חבילה לפי דרישות הקטלוג, מכינים קוד מקור והסברים לבודקים ומנהלים את ההתכתבות עד לפרסום — כדי שהמחזור לא ייצא לסבב שני ושלישי.
האפקט של שחרור מסודר: זמנים, סירובים, שחזוריות
האפקט המדיד הראשון — זמן צפוי מראש למעבר הבדיקה. כשהחבילה נבנית לפי תקנון אחד (מניפסט, הצדקה לכל הרשאה, היעדר קוד הנטען מרחוק, הצהרה על עיבוד נתונים), הביקורת מפסיקה לחזור על פורמליות. מחזור הבדיקה בקטלוג Mozilla הופך למתוכנן: שליחה אחת במקום סדרה של איטרציות «תיקון — המתנה — תיקון».
האפקט השני — ירידה בשיעור הסירובים. החזרה לתיקון נגרמת בדרך כלל לא מהלוגיקה של הקוד, אלא מהרחבת הרשאות בעדכון, מקוד מכווץ בלי קוד מקור מצורף ומנתונים שנאספים בלי מטרה מוצהרת.
הכלל «הרשאה חדשה מתווספת רק עבור פונקציה מוגדרת, עם הסבר בתיאור» מסיר כמעט לחלוטין את סוג הסירובים הזה — נשארים מקרים בודדים.
האפקט השלישי — בנייה משוחזרת. גרסאות תלויות מקובעות, בונה אחד וסדר קבצים דטרמיניסטי בארכיון נותנים תוצאה זהה אצל כל מהנדס בצוות. ההאש של החבילה הבנויה תואם לזה שנשלח לקטלוג, ולכן חזרה לגרסה חתומה קודמת אורכת דקות ולא בנייה מחדש מהזיכרון.
הרביעי — שחרור שקוף. יומן השינויים נכתב בשפת המשתמש, ערוצי היציב והבדיקות מופרדים, וכל עדכון מאושר בחתימה. הצוות רואה מה בדיוק קיבלו המשתמשים, והתמיכה — מאיזו גרסה הגיעה הפנייה.
דרכי אספקה לקטלוג: ידנית, אוטומטית, ערוץ נפרד
התוסף מגיע למשתמשים בכמה דרכים, והבחירה ביניהן קובעת מי אחראי לעדכונים ולבדיקת הקוד. המסלול המרכזי — הקטלוג Firefox Add-ons: הוא מפיץ עדכונים אוטומטית ובודק את הבנייה לפני ההפצה, אבל כל גרסה צריך לבנות, לחתום ולהעביר דרך ביקורת.
את שיטת האספקה בוחרים לפי תדירות השחרורים ולפי מידת הצורך בשליטה ידנית בכל שלב. להלן ארבעה וריאנטים עובדים והמגבלות שלהם.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| שליחה ידנית של החבילה | שחרורים נדירים, אחד-שניים ברבעון; נדרשת שליטה בכל שלב | הגרסה תלויה באדם, קל לפספס את שלבי הבנייה וההעלאה |
| בנייה ושליחה אוטומטיות | שחרורים סדירים, בנייה משוחזרת, יש בדיקות אוטומטיות | מפתחות הגישה נשמרים באופן מאובטח; כשהבדיקות נופלות השחרור נחסם כולו |
| ערוץ עדכונים עצמאי | הפצה בתוך החברה או יחד עם מוצר אחר | אחסון העדכונים, החתימה והתאימות נשארים באחריותכם, ההתקנה מתבצעת מחוץ לקטלוג |
| טעינה זמנית לבדיקות | בדיקת הבנייה לפני הפרסום, דיבוג על פרופיל חי | קיימת עד להפעלה מחדש של הדפדפן, אינה חתומה, אינה זמינה למשתמשים |
בפועל משלבים בין הווריאנטים: בשלב הפיתוח נוחה טעינה זמנית, לשחרור — שליחה אוטומטית לקטלוג, וערוץ עצמאי משאירים למעגלים סגורים שבהם התקנה מהקטלוג בלתי אפשרית.
שלבי הכנת התוסף: מאודיט ועד מסירה
את חבילת התוסף מפרקים הבודקים בקטלוג לחלקים: פותחים את הארכיון, משווים את הקוד המכווץ לקוד המקור ובודקים לשם מה מבוקשות כל הרשאה וכל דומיין. לכן «פשוט להעלות ארכיון» הופך למחזור של תיקונים ושליחות חוזרות שגורר את לוחות הזמנים של השחרור. אנחנו מנהלים את ההכנה כפרויקט עם שלבים קבועים — ובסופו חבילה שעוברת בדיקה מהניסיון הראשון-שני.
- אודיט של החבילה. מפרקים את הבנייה הנוכחית: אילו הרשאות באמת בשימוש, האם יש קוד הנטען מרחוק, האם נשארו קטעים מכווצים, איך נבנה הארכיון הסופי.
- התאמת המניפסט לדרישות הקטלוג. מצמצמים את ההרשאות לאלה שנדרשות בפועל, מסירים טעינה דינמית של סקריפטים, ומביאים את התיאור, האייקונים וההצהרה על עיבוד נתונים לפורמט של כרטיס.
- תרשים ערוצי העדכון. קובעים אילו בניות הולכות לערוץ הציבורי, אילו לערוץ הבדיקות הסגור, ואיך מתייחסים מספרי הגרסאות זה לזה, כדי שמעבר משתמש מענף הבדיקות לענף השחרור יעבור בלי נסיגות.
- הכנת קוד מקור לבדיקה. מרכיבים גרסת קוד קריאה והוראות לשחזור הבנייה — הבודק צריך לקבל בדיוק את הארכיון שמתואר בהוראות.
- שליחה לביקורת וליווי. רושמים טיוטה, עונים להערות, מבצעים תיקונים נקודתיים, בלי בנייה מחדש מלאה ובלי לאבד את היסטוריית הגרסאות.
- אוטומציה של ההפצה והעברה. הבנייה, החתימה והעלאת הגרסה החדשה מתבצעות בתרחיש אחד, ולכן תוכן הארכיון ומספר הגרסה לא מתפצלים. מוסרים את תרשים הערוצים ואת סדר המענה להערות — הצוות מפיץ עדכונים בעצמו.
החבילה בסיום: הגדרות, מדיניות, תיעוד
החבילה בסיום היא לא ארכיון של קוד מקור, אלא מערכת עובדת: לפיה מהנדס שלא השתתף בפיתוח מוציא עדכון. כל מסמך עונה על שאלה אחת — לשם מה התוסף צריך את ההרשאה הזו, איך לבנות ארכיון תקין, מה לבדוק לפני השליחה לביקורת.
- מדיניות הרשאות. טבלה «הרשאה — פונקציה — קטע קוד»: כל אחת מוצדקת, אלה שאינן בשימוש נחתכות. רוב ההחזרות מהביקורת ב-AMO נוגעות לפער בין הזכויות המוצהרות להתנהגות בפועל, ולכן רשימת הזכויות והתיאור בכרטיס נבדקים שורה מול שורה.
- תקנון הוצאת עדכונים. סדר שלב-אחר-שלב: להעלות גרסה, לבנות ארכיון, להריץ ולידציה, לשלוח, להמתין לבדיקה, לתעד את התוצאה. בנפרד מצוין אילו סוגי שינויים עוברים בדיקה אוטומטית ואילו נשלחים לביקורת ידנית.
- תיעוד הבנייה. פקודות הבנייה, הרכב הקבצים המוחרגים, היכן נמצא קוד המקור ואיך לצרף אותו אם הארכיון מכווץ או נבנה בטרנספילציה.
- צ'ק-ליסט לפני שליחה. הגרסה ומספר הבנייה אינם מתפצלים, המניפסט מפנה רק לקבצים קיימים, ההרשאות תואמות למדיניות, התיאור וצילומי המסך מעודכנים, מדיניות הפרטיות מפורסמת.
- תבנית הכרטיס. תיאור קצר ומלא, קטגוריה, מילות מפתח — תבנית שנותר רק לעדכן לפונקציונליות החדשה.
- סדר הנסיגה. מה עושים כשיש פגם אחרי הפרסום: איך מסירים את הגרסה הבעייתית, מוציאים תיקון ומיידעים את המשתמשים דרך תיאור העדכון.
המסמכים יושבים במאגר הקוד לצד הקוד, ולא בהתכתבות, ולכן חיים בדיוק כמה שהתוסף חי. אנחנו מוסרים אותם יחד עם הגישות לחשבון המפתח — פרסומים נוספים מבצע צוות הלקוח בעצמו.
מקרה בוחן: קיצרנו את מחזור הבדיקה והסרנו החזרות חוזרות
מה היה בנקודת הפתיחה
התוסף נבנה לקובץ מכווץ אחד, והמניפסט ביקש גישה לכל הלשוניות ולמארחים חיצוניים «ליתר ביטחון». הבדיקה של Firefox Add-ons בקונפיגורציה כזו לא יכולה להשתכנע שהקוד עושה רק את המוצהר, ולכן כל שליחה חזרה עם רשימת הערות חדשה.
מספר האיטרציות הגיע לארבע — קודם הזכויות, אחר כך קוד המקור, אחר כך פער בין הכרטיס להתנהגות בפועל; מועד יציאת העדכון נמתח לשלושה שבועות.
מה שינינו
בנינו מחדש את המניפסט: השארנו הרשאות מינימליות לפי מארחים, חלק מהלוגיקה העברנו מהרשאות קבועות לבקשה ברגע פעולת המשתמש. את הבנייה הפכנו למשוחזרת — התלויות מקובעות, השלבים מתוארים, ארכיון קוד המקור תואם לחבילה הבנויה.
הרצנו לינטר ובדיקה לשיטות אסורות (הרצת קוד חיצוני, ערפול) לפני השליחה, ואת התיאור בכרטיס התאמנו לאיסוף הנתונים בפועל.
| מדד | לפני | אחרי |
|---|---|---|
| איטרציות בדיקה לשחרור | 3-4 | 1 |
| שיעור השליחות שחזרו | כ-60% | פחות מ-10% |
| זמן יציאת העדכון | עד 3 שבועות | 4-5 ימים |
כעת העדכון עובר במעבר הראשון: הבודק מאשר את הזכויות המוצהרות ורואה התאמה בין קוד המקור לבנייה. החזרות חוזרות כמעט נעלמו, ותאריך השחרור הפסיק להיות בלתי צפוי — תכנון אבני הדרך נשען שוב על לוח השנה, ולא על התכתבות עם הבדיקה.
מה לעשות אם החבילה כבר נדחתה בידי המנהל?
דחיית חבילה היא לא גזר דין, אלא רשימה של הערות קונקרטיות: המנהל מציין אילו סעיפי מדיניות הקטלוג הופרו ומה בדיוק צריך לתקן. לרוב מדובר בהרשאות מבוקשות שאינן תואמות לפונקציונליות בפועל, בקוד שנטען מבחוץ, או בעיבוד נתוני משתמש שלא נחשף. הצעד הראשון — לקרוא את המכתב כולו ולרשום את ההערות לפי סעיפים, בלי לנסות לנחש את מניע הבודק.
מכאן — פירוק ההערות עם בדיקה מול הקוד. אנחנו משחזרים את הבנייה מקוד המקור, משווים את המניפסט לממשקים שבשימוש בפועל ומסירים הרשאות שבלעדיהן התוסף עובד: דווקא הפער «מבקשים יותר ממה שצריך» הוא שדוחה את רוב החבילות.
בנפרד עוברים על חיבורים חיצוניים ועל קוד שמורץ מרחוק — הקטלוג דורש שכל הלוגיקה תשב בתוך החבילה ותהיה ניתנת לסקירה בידי הבודק.
את התיקונים עושים נקודתית: סט שינויים מינימלי, בלי לשכתב בדרך את המודולים השכנים, כדי שבדיקה חוזרת לא תפתח שאלות חדשות. מעלים את הגרסה במניפסט ומכינים הסבר קצר לשליחה — שורה לכל הערה, עם ציון הקובץ ותמצית התיקון. כך הבודק לא צריך להשוות בין הבנייה הישנה לחדשה בעיניים עצומות.
השליחה החוזרת הולכת באותו ערוץ, כעדכון רגיל, יחד עם ההסבר הזה. אם ההערה שנויה במחלוקת או מנוסחת באופן דו-משמעי, כדאי יותר לא לשלוח את החבילה מחדש, אלא להשיב באותה התכתבות: בשקט, לפי סעיפים, בהפניה לתיעוד הפלטפורמה ובבקשה להבהיר איזה סעיף מדיניות בדיוק הוחל על מקום מסוים בקוד. שליחה חוזרת של בנייה זהה בלי מענה מאריכה את הבדיקה ומעלה את הסיכוי שהבדיקה הבאה תהיה מחמירה יותר.
פנייה למנהל היא כלי עבודה, לא עימות. נסחו את השאלה באופן ממוקד ולעניין, ותעדו את התשובות בתיעוד הפרויקט: כך בעדכון הבא אותן הערות לא יחזרו.
ספקות טכניים: הרשאות, מניפסט, עדכונים
ספקות לפני ההתחלה נוגעים בדרך כלל לשלושה דברים: האם רשימת הזכויות המבוקשות תרתיע את המשתמש, האם העדכון ישבור עותקים שכבר מותקנים, ומה בדיוק בודקת הביקורת. להלן איך אנחנו סוגרים כל אחד מהנושאים האלה בפרויקט.
האם אפשר להסתפק בסט הרשאות מינימלי?
כן, וזה העיקרון הבסיסי. יוצאים מהתרחיש: אם הפונקציה עובדת דרך הלשונית הפעילה ומארחים שמפורטים במפורש, אין צורך בבקשה לגישה לכל האתרים. בתיאור לכל זכות נותנים לבודק הצדקה — לשם מה זה נחוץ למשתמש, ולא «ככה זה נבנה».
מה לעשות אם התוסף נבנה על ענף מניפסט ישן?
מעבירים לענף העדכני: סקריפט הרקע הופך ל-service worker, ואת החלקים הנטענים מעבירים לתוך הבנייה. אם המוצר לא מוכן למעבר, משאירים את הענף הנוכחי וקובעים מועד שעד אליו חייבים לסגור את המיגרציה, כדי שהפרסום לא ייתקע.
איך עדכונים מגיעים לעותקים המותקנים?
מפרסמים גרסה — הדפדפן מושך אותה למשתמשים בעצמו, בלי מעורבותם. לבדיקות מחזיקים ערוץ נפרד: הבנייה הולכת לרשימה סגורה של בודקים, ורק אחרי אישור — לזרם הכללי. נסיגה נעשית בהעלאה חוזרת של הגרסה הקודמת, ומספר הבנייה תמיד עולה.
האם מותר לטעון קוד מהשרת?
לא, ואת המגבלה הזו מכניסים לארכיטקטורה מיד. כל הקוד המורץ חייב לשבת בתוך החבילה — סקריפטים חיצוניים וניתוח מחרוזות דינמי נדחים בביקורת. לוגיקה שתלויה בקונפיגורציה מוציאים לנתונים שהתוסף מקבל, ולא מריץ.
נדבר על המשימה: נשלח הערכה ותוכנית שחרור
כדי שהערכת המשימה תהיה עניינית ולא «פחות או יותר», די לצרף לבקשה כמה ארטיפקטים. לפיהם רואים את היקף התיקונים במניפסט, את מצב הבנייה ואת הסיכוי לחזרה מהביקורת — ומזה נבנית תוכנית שחרור עם שלבים ונקודות ביקורת.
מה לצרף לבקשה:
- קישור למאגר או ארכיון עם קוד המקור ופקודת בנייה שמשוחזרת מאפס.
- המניפסט הנוכחי: ההרשאות המבוקשות וההצדקה לכל אחת — ב-Firefox הבודקים מסתכלים על הסט המינימלי הנדרש.
- רשימת הבקשות ברשת והשירותים החיצוניים שאיתם התוסף מתקשר, ואילו נתונים נשלחים לשם.
- טיוטת הכרטיס בחנות: שם, תיאור, צילומי ממשק, לוקליזציה — אותם בודקים יחד עם הקוד.
- קישור למדיניות פרטיות או הטיוטה שלה, אם נאספים נתוני משתמש.
- פרטי חשבון המפתח והתפקיד שמטעמו מתבצע הפרסום: בלי בעלים מאומת אי אפשר להפעיל את ההעלאה.
- העדפות לגבי אוטומציה: העלאה ידנית של הגרסה או בנייה ושליחה לבדיקה לפי תג במאגר.
חלק מהחומרים אנחנו מכינים בעצמנו ומראים לפני תחילת העבודה — היעדרו של סעיף מהרשימה אינו סיבה לדחות את השיחה. תארו את המשימה כמו שהיא: נחזור עם הערכת המשימה ותוכנית שחרור שבה רואים את השלבים, האחראים והנקודות שבהן נדרשת ההחלטה שלכם.