לאחרונה פנה אלינו לקוח: לאחר שחרור עדכון מינורי, האפליקציה החלה לקרוס במכשירי iOS 15 — התברר שהתכונה החדשה השתמשה ב-API שזמין רק מ-iOS 16, אך יעד המינימום עדיין היה 15. התוצאה — תיקון דחוף (hotfix) ופגיעה במוניטין. מצבים כאלה נוצרים כאשר אסטרטגיית הגרסאות אינה מתחשבת בתאימות לאחור. אנו עוזרים לבנות תהליך שבו כל עדכון — מ-patch ועד major — עובר בדיקות תאימות ושחרור מדורג.
סמנטיקת גרסאות בהקשר מובייל
Semver (Major.Minor.Patch) פועל אחרת בפיתוח מובייל מאשר בתוכנת שרת. versionName הוא מחרוזת שיווקית עבור המשתמש. versionCode (אנדרואיד) ו-CFBundleVersion (iOS) הם מספרים עולים באופן מונוטוני עבור חנויות האפליקציות. חוסר סנכרון ביניהם הוא מקור אמיתי לבעיות.
Patch (x.x.N): תיקון דחוף לקריסה, תיקון שגיאת כתיב, תיקון תרגום שגוי. הגדל את versionCode, שנה מעט את versionName. עבור iOS, ניתן להשתמש ב-CFBundleVersionString מבלי לשנות את CFBundleShortVersionString — אך החנויות עדיין דורשות בדיקה.
Minor (x.N.0): תכונה חדשה, שינוי ממשק משתמש, הוספת מסך חדש. אין Breaking Changes. המשתמש מעדכן — שום דבר לא נשבר.
Major (N.0.0): שינוי סכימת מסד הנתונים המקומי (מיגרציית Room, מיגרציית CoreData), שינוי גרסת מערכת הפעלה מינימלית, רפקטורינג עם שינויי מבנה נתונים. יש צורך באסטרטגיית מיגרציה — נתוני המשתמש חייבים להיות מועברים כראוי.
השוואה בין סוגי עדכונים
| פרמטר | Patch | Minor | Major |
|---|---|---|---|
| זמן הכנה | 1–2 ימים | 3–5 ימים | 1–3 שבועות |
| מיגרציית נתונים | לא | לא | חובה |
| שחרור מדורג | אופציונלי | מומלץ | חובה |
| בדיקת חנות | כן | כן | כן |
איך להתכונן לשחרור Major עם מיגרציית נתונים?
החלק הכואב ביותר הוא Major עם מיגרציה. Room ו-CoreData מספקים מנגנונים אך דורשים תכנון קפדני. בעיה אופיינית: מפתח מוסיף שדה לישות, מגדיל את version ב-@Database, אך שוכח לכתוב אובייקט Migration — Room זורק IllegalStateException: Room cannot verify the data integrity בעת ההפעלה עבור משתמשים עם הגרסה הקודמת.
עבור CoreData, שגיאה דומה — שינוי המודל ללא מיגרציה קלה (lightweight migration) או ללא מודל מיפוי מפורש. האפליקציה קורסת במכשירים עם נתונים קיימים, למרות שהיא עובדת כראוי על התקנה נקייה.
אסטרטגיה למיגרציות מורכבות: גיבוי עם fallbackToDestructiveMigrationFrom רק אם אובדן נתונים מקובל. ברוב המקרים, כתוב Migration מפורש עם סקריפט SQL. בדוק את המיגרציה על נתונים אמיתיים מהגרסה הקודמת, לא רק על מסד נתונים ריק. הניסיון שלנו מראה ש-80% מהבעיות עם שחרורי major קשורות למיגרציה. לדוגמה, אחד הלקוחות שלנו הפחית את שיעורי הקריסות במהלך עדכונים ב-40% לאחר יישום בדיקות מיגרציה.
שלבים להכנת שחרור Major
- ניתוח שינויי סכימה.
- כתיבת סקריפט מיגרציה SQL.
- בדיקה על הגרסה הקודמת עם dump של מסד נתונים אמיתי.
- הגדלת versionCode / CFBundleVersion.
- התחלת שחרור מדורג עם ניטור Crashlytics.
למה שחרור מדורג הוא חובה לעדכונים?
שחרור מדורג — הפצה הדרגתית של העדכון (לדוגמה, 5% → 10% → 20% → 100%). זה מפחית את הסיכון לכשלים המוניים: אם מתגלה קריסה ב-5% הראשונים של המשתמשים, אנו מחזירים את השחרור מבלי להשפיע על השאר. שחרור מדורג יעיל פי 10 משחרור מסורתי — אנו מקצים 24 שעות ניטור לכל שלב. צור קשר כדי להגדיר שחרור מדורג.
אנדרואיד: בנה AAB, חתום, העלה ל-Play Console. אנו משתמשים בשחרור מדורג — התחל עם 5–10%, ניטור Android Vitals (שיעור קריסות, שיעור ANR) למשך 24 שעות, ולאחר מכן הרחב. עבור עדכוני patch, ניתן להאיץ את השחרור. עבור Major — עצירה חובה בכל שלב.
iOS: בנייה דרך Xcode Cloud או Fastlane עם gym. העלאה דרך Transporter או fastlane deliver. אנו משתמשים ב-Phased Release (7 ימים, ב-1–2–5–10–20–50–100%) עבור עדכונים מינוריים ו-major. עבור hotfix, ניתן לדלג על Phased Release, אך הבדיקה עדיין לוקחת זמן.
אוטומציה דרך Fastlane: lane :release עם increment_build_number, בדיקות, בנייה והעלאה. CI/CD דרך GitHub Actions או Bitrise — כל מיזוג ל-main לאחר מעבר בדיקות מכין בנייה ל-TestFlight/Internal Testing. אנו מבטיחים שכל שחרור עובר דרך צינור זה. הזמינו ביקורת על תהליך השחרור שלכם — נזהה צווארי בקבוק ונציע שיפורים.
שלבי שחרור מדורג
| שלב | אחוז | משך | מדדים |
|---|---|---|---|
| ראשוני | 5% | 24 שעות | שיעור קריסות, ANR |
| ביניים | 10–20% | 24–48 שעות | משוב, מדדים חיוניים |
| סופי | 50–100% | 24 שעות | כל המדדים |
מה כלול בעבודת השחרור שלנו?
אנו מציעים מחזור מלא של שחרור עדכונים:
- פיתוח אסטרטגיית מיגרציה עבור Room/CoreData.
- הגדרת CI/CD (Fastlane, GitHub Actions, Bitrise).
- הכנת הערות שחרור בכל השפות.
- בדיקת תאימות לאחור עם ה-API של השרת.
- שחרור מדורג עם ניטור Crashlytics.
- הבטחת עדכון חלק למשתמשים.
ציר זמן: patch — 1–2 ימים, minor — 3–5 ימים, major — 1–3 שבועות כולל בדיקות מיגרציה. העלות מחושבת באופן אישי.
הניסיון של הצוות שלנו — 10+ שנים בפיתוח מובייל, יותר מ-50 שחרורים בשנה. קבלו ייעוץ על תהליך השחרור שלכם — נעריך את הפרויקט שלכם ונציע את הפתרון האופטימלי.