איך מחליפים אפליקציה למאות אלפי משתמשים עם מינימום תקלות?‎

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

מקור: Pixabay

מאת: יון ברגמן

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

עקרון ההדרגתיות

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

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

בדיקה ראשונית פנימית או חיצונית

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

מהצד השני, יש אפשרות לשחרר את המסכים השונים של האפליקציה בצורה הדרגתית לשווקים שונים (במקרה שלנו, קודם ל-5 בניינים בניו-יורק, אחר כך לכל העיר, לכל המדינה ולבסוף מדינות נוספות) כך אפשר לקבל פידבק של משתמשים אמיתיים ולבדוק את האפליקציה תחת עומס אמיתי.

בניית מנגנון Feature Flagging רובוסטי

יצירת מנגנון שירות מתאים לתהליך התאפשרה בראש ובראשונה בזכות בניית מנגנון Feature Flagging רובסטי. יש צורך להכין מנגנון שיידע להציג חוויות למשתמשים על סמך מספר רב של מאפיינים, בנוסף צריך לוודא שמסביב לפתרון הטכנולוגי אתם בונים גם תהליך סדור ובריא שמאפשר להתמודד עם תחזוקה של מספר רב של קומבינציות אפשריות בכל רגע נתון. היום, אפילו לא צריך לכתוב את מנגנון ה-Feature Flagging כולו בעצמכם, יש מספר שירותי SaaS שייתנו לכם את הכלים כדי להגדיר, לנהל ולתחזק את אותם דגלים באפליקציה שלכם, החל מ-LaunchDarkly, Split.io, Pertry ו-Optimizly. אותם כלים נותנים לכל אפשרות לנהל דגלים ו-A/B Testing בלי הצורך לכתוב את מנגנון הניהול בעצמכם.

קשיים אפשריים

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

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

בטור זה סקרנו את האופציות שעומדות בפני חברה כאשר היא מתמודדת עם Rewrite או Redesign של אפליקציה. השווינו בין האופציה הקלאסית (הדומה למודל הווטרפול) בה מחכים עד שכל האפליקציה מוכנה עד השדרוג ומודל יותר אג׳ילי שמאפשר לשחרר חלקים באפליקציה הדרגתית.

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

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

הכותב הוא סמנכ”ל טכנולוגיה במרכז הפיתוח של WeWork בתל אביב

 

כתב אורח

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

הגב

4 תגובות על "איך מחליפים אפליקציה למאות אלפי משתמשים עם מינימום תקלות?‎"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
אלכס
Guest

לא קונה את זה, נראה לי כמו בדיחת 1 באפריל…

Ron b
Guest

Hybrid application dude…

Ron b
Guest

Hybrid app dude…

Mike
Guest

Also Rollout.io – an Israeli feature flagging solution, we use them and they are great!

wpDiscuz

תגיות לכתבה: