logo

105: סדרת R&D 02 – איך שדרגנו את ה-framework שלנו במינימום סיכון

Startup For Startup

 

דריה:             היי כולם, אני דריה ורטהיים ואתם הגעתם ל-Startup for Startup, הפודקאסט שבו אנחנו חולקים מהניסיון, מהידע והתובנות שיש לנו כאן במאנדיי.קום וגם מחברות אחרות. הוא מיועד לכל מי שסטארט-אפ מדבר אליו, לא משנה באיזה כיסא הוא יושב ברגעים אלו [מוזיקה]. ברוכים הבאים למיני-סדרה שלנו על R&D. סדרה שבמהלכה נשתף בעקרונות, בתרבות ובתהליכים של מחלקת ה-engineering במאנדיי.קום. באמצע 2019 התקבלה החלטה שהגיע הזמן לשדרג את ה-framework של מאנדיי. לאלו מכם שלא מבינים מה זה אומר, תיכף ניכנס לפרטים המלאים. אבל מדובר בסוג של עדכון גרסה לפלטפורמה, תהליך שדורש הכנה ארוכה מאוד ומועד ללא מעט סיכונים, כמו אובדן data, פרצות אבטחה, ועוד כל-מיני scenarios לא ממש סימפטיים. כשמחלקת ה-R&D החליטה לבצע את השדרוג הזה דבר אחד היה ברור – אם עושים אותו אז עושים אותו עם אפס תקלות. אז היום מצטרפים אליי אביתר מוצפי, Full stack lead, ועומר דורון, full stack developer במאנדיי.קום, שהיו אחראים על כל תהליך שדרוג ה-framework. הם ישתפו אותנו מה היה תהליך המחשבה מאחורי הפרויקט, איך לוקחים תהליך כזה שמלא בסיכונים והופכים אותו לבטוח כמעט לחלוטין, ומה היו מנגנוני ההגנה שהם השתמשו בהם בשביל שהפרויקט באמת יצליח. רגע לפני שנמשיך, חשוב לציין שהפרק הפעם הוא טכני במיוחד, שהוא צולל עמוק לתוך עולמות הפיתוח, הוא מתאים בעיקר לאנשים מהתחום. היי אביתר.

אביתר:           היי.

דריה:             היי עומר.

עומר:             אהלן.

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

אביתר:           כן, אז נראה לי ששווה גם להסביר קצת מה זה אומר וגם איך זה בנוי במאנדיי. בסוף יש לנו את האפליקציה, אנחנו web application, יש לזה client site, יש לזה server site. ופה אנחנו מדברים על שדרוג של ה-server site application שלנו. מבחינה טכנולוגית יש לנו, כמו שבטח גם להרבה מהמאזינים יש, מונולית, שזה אומר איזושהי גרסה גדולה, עם המון קוד, עם המון complexity, שכבר רצה הרבה שנים. וספציפית בטכנולוגיה שנקראת Ruby on rails. כש-Ruby זו שפת תכנות, rails זה בעצם ה-framework, שזה המסגרת מעל. שמביאה את כל היכולות של ה-web application. ויש לנו micro services, שכתובים ב-Note GS. זה מבחינת קצת ה-stack הטכנולוגי שלנו. ופה אנחנו באמת רוצים לדבר על השדרוג של ה-framework של rails בתוך המונולית.

דריה:             מעולה. אז אוקיי, אז אני אמרתי בפתיח ששדרגנו את rails ב-2019, אבל בעצם זה קרה, ההחלטה לשדרג קרתה הרבה לפני. נכון?

עומר:             כן. ראינו שיהיה לנו המון value מלשדרג את הגרסה כבר ב-2018, בערך שנה לפני שעשינו את השדרוג. יש לזה המון השלכות, מעבר ל, תמיד צריך מבחינת security להיות בגרסה שהיא up to date עם כל עדכוני האבטחה, גם זה, ברגע שיש גרסה ישנה אז כל הקוד שהוא open source שעובדים איתנו באינטרנט וכל הדוקומנטציה מתחיל לא לעבוד וביחד עם ה-framework. וזה מאוד מקשה על הפיתוח, גם על החוויה של המפתחים וגם ממש לא מאפשר לעדכן גרסאות של כל-מיני דברים במערכת. אז מה שעשינו, התחלנו בעצם לשדרג את ה-framework. זה משהו שאני עבדתי עליו בערך חודשיים אני חושב, וממש הגענו למצב שהכול עובד, כאילו, כל המערכת עובדת, עם ה-framework מעודכן, כל הפיצ'רים עובדים, כל הסביבה הלוקאלית, כל הטסטים רצים, נראה מדהים. אבל מה, ואז התחלנו לדבר איך עושים לזה release ליוזרים. והבנו שזה דבר שהוא קצת בעייתי, או אפילו מאוד בעייתי. זה לא כמו הרבה פעמים שאפשר לשים לזה feature flag שהוא דולק רק ל-account שלנו או לא, כאילו, זה משהו יותר מורכב, כי בעצם כל המערכת רצה עם זה,

[00:04:00]     אז  בבת אחת לעשות לזה deploy ולפרוש את זה על כל השרתים, יש לזה המון סכנות. והחלטנו לשבת ולחשוב איך אנחנו עושים את זה. וכשדיברנו על זה שנה קודם הגענו למסקנה שאנחנו אפילו לא בטוחים איך אנחנו יכולים לעשות את זה בגרסה בטוחה, וגם התייעצנו עם כמה אנשים מחברות אחרות שעברו את אותו תהליך, שמי שדיברנו איתו הם פשוט החליטו לא לעשות את זה בגלל הסכנות שכרוכות בזה-

דריה:             לא לשדרג בכלל, להישאר עם אותה גרסה.

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

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

אביתר:           הסיכונים הם מטורפים פה, והם גדלים ככל שהמערכת יותר מורכבת. בסרוויס קטן, במערכת פשוטה, אפשר ממש לבדוק את הכול, להבין את הכול לעומק. פה יש קוד שנכתב למספר שנים, עם המון המון עומק, אלפי flows. שהיכולת לבדוק את כולם ואת ההשפעה של כולם היא, מאוד קשה להגיע לרמה הזאת. וה-risk management פה זה בעצם בכמה רמות, כן? הכול פה גרוע רגע, אבל הכי גרוע זה security breach. אנחנו פתאום מחליפים משהו, אנחנו משדרגים את ה-jam לדוגמה. Jam ב-Ruby זה package, שזה אומר פיסת קוד open source שאנחנו משתמשים בה. אנחנו משדרגים את ה-Jam של איך עושים log in למערכת. עכשיו, נגיד שיש שם באג, מישהו יכול לעשות סיסמה לא נכונה ולהיכנס לחשבון אחר – לא קרה שום דבר כזה, אבל ההשלכות של משהו כזה, זה הרסני כלפי החברה. ש-data ידלוף החוצה בין לקוחות על security זה ה-main concern פה, זה הדבר הראשון והכי הכי חמור. הדבר השני, שהוא גם מאוד חמור, זה כל מה שקשור ל-data. אוקיי? נגיד שאנחנו משדרגים את הדבר הזה, הכול נראה טוב, ופתאום אחרי יום-יומיים לכל-מיני לקוחות נעלם ה-data, הם לא מצליחים, ועכשיו אנחנו באיזושהי… אנחנו לא יודעים איך לחזור אחורה, אנחנו פתאום באיזשהו מצב שאיבדנו ללקוחות שלנו פיסות מידע, יש… זה קורה הרבה פעמים במערכות מורכבות, שיש מנגנוני cashing-

דריה:             כן, אז פה אפילו יכול להיות מצב שאי אפשר יהיה לשחזר את המידע הזה אתה אומר.

אביתר:           בדיוק, שהם איבדו את המידע, זה מה שנקרא data loss.

דריה:             וואו.

אביתר:           [צוחק] וזה גם, כמובן, חמור מאוד מאוד. מעבר לעוד, כאילו, המון דברים שהם כאילו דומים, כן? זאת אומרת, אולי פחות מלחיצים אבל עדיין חמורים. performance, אנחנו תמיד, ה-scale שלנו תמיד מאתגר, מבחינת כמות הבקשות, כמות היוזרים שיש לנו. עכשיו בוא נגיד ששדרגנו גרסה ופתאום המערכת רצה פי שתיים יותר לאט. זה אומר שגם כשנשדרג ונעביר את כולם אנחנו נהיה למטה. ה-database אולי לא יעמוד בזה כי השליפות פחות יעילות כי הן השתנו טיפה, או פתאום הוא לא משתמש באינדקסים שהוא השתמש בהם קודם. זה פשוט יכול ממש לתקוע את המערכת. וכמובן, באגים, כן? [צוחק] בסוף שדרוג כזה, לא איכפת ללקוחות, כן? הם, כאילו-

דריה:             כן, זה משהו שהלקוח בכלל לא אמור לשים לב אליו, נכון? זה, אם זה הולך חלק-

אביתר:           הוא לא אמור לדעת שזה קרה. זה מה שזה נקרא לעשות את זה טוב, זה הלקוח לא יודע. זה לא עכשיו איזה schedule down time להוריד את המערכת ליום. אנחנו כאילו, כל הקונספט שלנו, המערכת צריכה להיות ב-upline כמה שיותר גבוה. אין לנו את הפריבילגיה להגיד "טוב, עוצרים רגע ליום, מורידים את האפליקציה לכל הלקוחות ותחזרו מחר." זה, כאילו, זה בדיוק מה שאנחנו לא רוצים, כאילו, ממש לא רוצים, לעשות, בוא נקרא לזה ככה.

[00:08:00]

עומר:             בנוסף לזה, יש גם את הנושא של backward compatibility. זה  אומר ש, נניח עשינו את כל הבדיקות, אנחנו חושבים שהכול בסדר. למרות שתמיד ב-production ה-flows של היוזרים הם יהיו שונים, בהרבה או במעט, מה-flows של הבדיקות של סביבת testors staging. ונגיד רק אחרי יומיים גילינו שיש איזושהי בעיה ואנחנו חייבים לחזור אחורה. יכול להיות שהמידע ממש ב-database, ב-framework בגרסה החדשה, כבר נשמר בצורה אחרת. לא כי תכננו, כי יכול להיות שיש איזה שינוי שלא היינו מודעים אליו. ואם פתאום נחזור אחורה המערכת תהיה למטה. ואז זה יכול להיות מצב שנגיד, נגיד יש איזה breach, או שיש איזה data loss או כל מה שדיברנו עליו שאביתר הזכיר, החלטנו, בתור התחלה עוצרים את הכול, אולי זה קרה רק לאיזה subset של היוזרים או של ה-flows, ואז בוא נחשוב שנייה שזה קורה ורוצים לחזור אחורה ואם אי אפשר לחזור אחורה, פשוט נתקעים באמצע.

דריה:             וואו. מציאות, בקיצור [צוחקת].

אביתר:           כיף חיים, כיף חיים.

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

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

דריה:             ולעשות טוב.

אביתר:           ולעשות טוב. וזה באמת באמת מסובך. אבל אפשרי.

דריה:             אוקיי, אז באמת, אז איך עושים את זה?

עומר:             דיברנו על זה שוב, זה עלה מכל הכיוונים. הבנו שאנחנו חייבים לשדרג. אני שנייה אעצור ואגיד מה האלטרנטיבה, שגם הבנו שלפעמים חברות אחרות עושות, זה שאומרים "אוקיי, את המונולית לא משדרגים, מתחילים לפרק אותו, ואז להעביר את הקוד ובעצם לכתוב אותו מחדש כבר ב-framework אחר, שאצלנו נגיד, במקרה שלנו זה Now GS, כל ה-micro services, ולאט-לאט לפרק את המונולית.

דריה:             שלמה מבחינתנו זו לא הייתה אופציה טובה?

עומר:             זה משהו שנגיד היינו עוצרים את כל הפיתוח של החברה לשנה, שמים על זה את כל ה-R&D ובמקרה הטוב היינו מספיקים, לא יודע, 50 אחוז מהמונולית לפרק אותו. זה פשוט כמות קוד ופיצ'רים ו-flows ולעשות את זה בזמן עוד שיוזרים עובדים עם המוצר זה, זה כאילו, זה אפשרי, זה פשוט לקחת המון המון resources שאולי אפילו באותו הזמן זה היה אפשר להגיד סוג-של בלתי אפשרי במצב שלנו, ולעצור את הכול לשנה. וגם לא בטוח שאפילו בשנה נספיק לכתוב את כל הקוד מחדש.

דריה:             כן, גם חשוב להגיד שמחלקת ה-R&D שלנו היא די lean כאילו, לא מחלקה סופר-גדולה ביחס לחברות אחרות נראה לי בגודל שלנו. אז כשלוקחים משאבים לפרויקט כזה זה אומר בהכרח שלא משקיעים משאבים בדברים אחרים שצריכים פיתוח.

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

דריה:             כן.

עומר:             זה יותר אינקרמנטלי וחלקים יותר קטנים, אבל זה לא פותר את הבעיה. לפעמים לשדרג באותה שפת תכנות, באותו framework, או נגיד Jam שזה package שהוא open source ש … גרסה יש דוקומנטציה איך לשנות ו… לפעמים זה אפילו יותר קל מלכתוב את הקוד מחדש.

דריה:             כן.

אביתר:           אבל אנחנו כן מפרקים את המונולית ל-micro services, זה תהליך שהוא ongoing. אנחנו עושים אותו ברובו, הפרדנו בין הדברים. ואני חושב שהעניין של זה שאנחנו באמת R&D שהוא lean זה עניין ממש חשוב פה. כי מה שתיכף נדבר עליו זה איך עשינו את זה שלושה אנשים את כל הדבר הזה בערך בחודשיים עבודה, במקום לשכתב את הכול. כלומר, בסוף באנו ועשינו, וזה היה עבודה, זה היה אינטנסיבי וזה היה קשוח, אבל עשינו את זה טוב וגם עשינו את זה יעיל.

[00:12:00]     עשינו את זה בלי לעצור את כל שאר האנשים. אפילו לא עצרנו אותם לשבוע להגיד כולם עכשיו על זה, מה שצריך לעשות זה בצוות קטן ובצורה  יעילה, שאני חושב שזה, זה גם חלק מהאתגר, איך עושים R&D שיכול לרוץ מהר ועדיין לעשות את האתגרים הטכנולוגיים המורכבים בלי שאומרים "טוב, לכל דבר שזה מורכב צריך לעצור את כולם ועכשיו שבוע זה." אנחנו לא יכולים להרשות לעצמנו, זה לא הדבר היחיד שעשינו.

דריה:             לגמרי. אז באמת גם במילה, מי האנשים שעבדו על זה, מי הצוותים שעבדו על השדרוג הזה?

אביתר:           אני היום ב-server foundations. בזמנו זה נקרא Platform 1. עוד לא היה לנו הבדלה מעניינת בין הצוותים. אז אני ותות מ-Platform 1, עומר מ-Platform 2. ודוד, שהוא ה-Head of Infra, המון תמיכה מהצד של האינפרה, שזה נגיע למנגנונים ואיך הקטנו את ה-risk, זה היה המון עבודה עם האינפרה. ואנחנו בעצם עשינו את כל ה-heavy lifting.

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

עומר:             אם נתחיל מהתהליך לפי הסדר שהוא היה, אז דבר ראשון, התחלנו לגרום לסביבה לעבוד. וכבר פה יש את השלב הראשון של להוריד את ה-risk, שבעצם הרבה פעמים כשמשדרגים אומרים "טוב, בוא נשדרג את הכול לגרסה הכי חדשה." ודווקא בשדרוג של framework עדיף לעשות בדיוק את ההיפך. בוא נשדרג את המינימום של הג'אמים במקרה של Ruby on rials, כדי שהסביבה תעבוד. ואז אני גם ממזער ריסקים, גם לכל jam בפני עצמו לשדרוג שלו יש risk. אז החוכמה זה למצוא את הגרסה הכי דומה לגרסה המקורית של כל jam, שעובדת עם הגרסה החדשה. ובנוסף לזה כשמגיעים למצב שזה כבר עובד ומוציאים את הגרסאות, זה לבדוק איזה מהג'אמים האלה עובדים גם עם ה-framework בגרסה הקודמת שלו ואם אפשר בכלל את העדכון הזה לעשות לפני השדרוג של ה-framework. בעצם כל פעם שלוקחים משהו ומעדכנים אותו בפני עצמו, זה משהו שהוא הרבה יותר אינקרמנטלי וקטן וקל לעקוב אחריו ולעשות לו release הרבה יותר בטוח.

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

עומר:             נכון.

אביתר:           כל שינוי שיכולנו להכניס בגרסה הישנה, ואפשר לעשות לזה deploy ל-production, זה מה שעשינו. אנחנו בכללי, כשאנחנו מעלים קוד – וזה ב"אני מאמין" שלנו ב-R&D, זה אפילו בלי קשר לפרויקט הזה – זה באינקרמנטים קטנים, אנחנו רוצים שהקוד יהיה חי ב-production, אנחנו משתמשים הרבה ב-feature flags ו-gradual release כדי שזה לא ישפיע על לקוחות עד שזה לא כתוב ובדוק עד הסוף. אנחנו רוצים אינקרמנטים קטנים. ככה זה עובד לנו הכי טוב. אז כל דבר שאפשר לעשות בגרסה הישנה, ואז השינוי לגרסה החדשה נעשה יותר קטן, בעצם הדלתה של השינויים קטנה, זה מקטין לנו את ה-risk. וזה מעולה. אז אם אני יכול לקחת גרסה של package שעובדת גם פה, גם בגרסה הישנה של rails וגם בגרסה החדשה, אני אעדכן אותו בגרסה הישנה. ואז אני לא צריך להתעסק עם זה בשינוי, והשינוי נעשה יותר קטן. זה גם ככה היה אלפי קבצים. [צוחק] אז מעדיפים שזה יהיה יותר קטן. בכל מקום שאפשר.

דריה:             מה השלב הבא?

עומר:             לעקוב אחרי המדריכים של השדרוג. יש הרבה אנשים שעשו את זה קודם, כתבו על זה גם את המדריך official, גם בכל-מיני אתרים. ממש עקבנו אחרי המדריך וגרמנו לכל הסביבה לעבוד במחשב הלוקאלי. זה השלב הראשון.

דריה:             אוקיי. אז עכשיו כביכול נראה שהוא עובד אצלנו, לוקאלית.

עומר:             כן.

דריה:             מה השלב הבא, כבר משחררים את זה ישר לכולם?

עומר:             אה, אז לא [צוחקים], יש עוד כמה שלבים בדרך.

דריה:             יש עוד איזה חודש-חודשיים שפספסתי בדרך.

עומר:             כן. אז השלב הבא זה מה שהזכרתי קודם, זה עם הטסטים. השלב אחרי זה זה כבר בעצם לדבר על מנגנונים הבאים שיגרמו ל-release הזה להיות risk free.

עומר:             זה לא היה סגור לנו בראש במאה אחוז. עשינו את הדבר הזה, אנחנו דוחפים את זה, אנחנו יודעים שזה חייב לקרות, כן? ואז דניאל אריה, ה-VP R&D, כן? בא ואומר כאילו, "איך אתם מבטיחים לי שאין פה data loss? איך אתם מבטיחים לי שאין פה security breach? עזבו שנייה זמן, עזבו שנייה איטרציות – איך אתם דואגים שהדבר הזה מה שנקרא הוא risk free?" בשלב הזה של הפרויקט זה לא היה סגור לנו בראש.

[00:16:00]     אנחנו היינו כזה מין "אוקיי, מתקדמים, אנחנו יודעים מה צריך לעשות, אנחנו קוראים את המדריכים, אנחנו משדרגים פה, הנה, מצאתי באג – תיקנתי, באג – תיקנתי." אבל זה עוד לא היה לנו בראש הקונספט הזה בכלל של איך עושים את השדרוג הזה risk free, שאין שום סיכוי כאילו, ש-something will go wrong.

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

אביתר:           ואז כאילו ממש כזה, אני חושב שהיה שם שינוי תפיסתי אחרי הפגישה הזאת. שזה ממש חלחל. שכאילו, בסדר, בואו נחשוב קצת מחוץ לקופסה. עזבו שנייה את המדריכים, הם סופר-חשובים, כן? אבל מה יש לנו לעשות מעבר. ברמה הקונספטואלית, בעיה תאורטית, כן? איך פותרים את זה risk free. סתם לדוגמה, אחד החששות הכי גדולים שדיברנו עליהם זה שה-data יהיה תקין. שיש לנו המון מניפולציות על data, ה-data יושב בסוף ב-database, זה עובר דרך ORM, שזה כאילו, זה חלק של השפה שזה כותב quarries ו-database עבורנו, נקרא active record ב-rails. והספרייה הזאת השתנתה מאוד. עכשיו, איך אנחנו יודעים שה-data ב-database הוא תקין וגם שהוא backwards compatible?

עומר:             אחד הדברים שבעצם איך שהאינטרנט, אתרי אינטרנט עובדים, שיש איזה בקשות מה-browser והן מגיעות לשרת. השרת עושה איזה processing, מעדכן את ה-database, מחזיר את התשובה לבראוזר. אם חשובים על זה כאילו, על בעצם, במקרה שלנו כמובן זה בקשות http, זה שאם ננגן את אותן בקשות http לפי סדר מסוים, אז אם המידע ב-database אמור להתנהג אותו דבר – כי אנחנו מעדכנים את אותו מידע, את אותה טבלה – אז בעצם התוצאה הרצויה זה בסוף איך המידע נשמר ב-database. אז אם ננגן את אותן בקשות ב-framework הישן או החדש, אנחנו מצפים עד רמת ה-byte ב-database שהמידע יהיה זהה לחלוטין. לא שאם אני אעשה dump, שזה export של כל הטבלאות ב-database ואני אשווה אותן תו-תו את כל התוכן, זה אמור להיות זהה לחלוטין. אז עשינו, איך שאנחנו עשינו את זה, באותה תקופה לוקאלית הרצנו, השרת הלוקאלי עבד עם NG mix לוקאלי. הוספנו איזה לוג ל-NG mix. שכל בקשה שנכנסת אליו היא גם נשמרת בלוג בצד. שזה, נגיד אני רוצה לעדכן את ה, איך שזה עובד זה כאילו, ממש יש payload לכל בקשה. של נגיד, פונים ל-controller מסוים עם data מסוים, בעצם כל הג'ייסון של הבקשה וכו', עם הדרים מסוימים. ומה שהחלטנו לעשות זה לנגן את הבקשות באותו סדר גם לגרסה הישנה של rails וגם לגרסה החדשה שלו. אז הרצנו את זה לוקאלית. וניגנו את הבקשות. אז בשלב הראשון, נגיד סתם, נגיד התחלתי ברמה הכי בסיסית, לעשות log in, ובמאנדיי יש פולסים, היום זה אייטמים. אז עדכנתי אייטם, שיניתי לו את הסטטוס ל-done, הוספתי, עשיתי לו duplicate, מחקתי אותו מהר מאוד, הקלטתי איזה 10-20 בקשות. אוקיי, הן שמורות לי בקובץ בצד. עכשיו יש בעצם איזו תוכנה שכתבנו, req-play, כי זה request replayer כזה. שהוא מושך את כל הבקשות ומנגן אותן לפי הסדר. אז תחשבו על זה שנגיד יש בקשה, מנגנים אותה, פעם אחת שולחים אותה ל-local host עם איזה port מסוים. פעם שנייה שולחים אותה ל-local host עם port אחר. שבעצם על המחשב rails מותקן פעמיים – פעם אחת עם הגרסה הישנה, פעם אחת עם הישנה. אז שולחים את זה לפה, שולחים את זה לפה. אחרי זה לוקחים את הבקשה השנייה, שולחים אותה לפה, שולחים אותה לפה. אחרי כל כמה בקשות עצרנו, ופשוט כתבנו סקריפט שמייצא את כל התוכן מה-database וממש משווה אותו תו-תו.

דריה:             והמטרה שלנו היא לבדוק שזה מתפקד באותה הצורה.

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

[00:20:00]     ואז ראינו שזה time stamping כי בעצם זה גם נשמר ב-databases, ממש באיזה מילי-שנייה נוצרת הבקשה. ואז כשמושכים את זה, אז פתאום רואים "רגע, זה לא אותו time stamp", אבל הבנו שזה הגיוני, כי לא ניגנו את הבקשה בדיוק באותה מילי-שנייה. אז עשינו בהתחלה exclude כזה לפטרנים של תאריכים ודברים כאלה, כאילו, רצינו לבדוק את העיקר, לא להתעסק בדברים שהם בטוח לא יעבדו. ואז גילינו משהו מאוד מעניין. ראינו באיזה flow מסוים שאיזה data נשמר אחרת. וזה היה מטורף, כי אמרנו "וואו, כמה כוח הכלי הזה נותן לנו." ישר הבנו למה זה קורה כשהסתכלנו על הקוד, והיה מאוד קל לתקן את הבאג. ואני לא חושב שיכולנו לעלות עליו בדרך אחרת.

דריה:             אז זו דרך לזהות באגים עוד לפני שהם קורים בעולם האמיתי.

עומר:             כן.

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

עומר:             כן.

אביתר:           וזה גם מבטיח לנו, או מאוד עוזר לנו, ל-backwards compatibility. כי אנחנו יודעים שה-data הוא זהה, זה אומר שאם היינו בגרסה החדשה של rails, משנמכים אותה לגרסה הישנה, הכול היה עובד, כי ה-data הוא תקין. ה-data הוא שמור אותו דבר, עד כדי הבדלים שאנחנו יכולים לבדוק שעובדים גם וגם. וברגע שאנחנו יכולים לעשות את זה זה המון ביטחון ביכולת שלנו ללכת קדימה ואולי גם לחזור אחורה כשצריך. ואני חושב שהדבר הכי מדהים בכלי הזה, שעומר עשה, אבל באמת הכי מדהים, זה פשוט המהירות של זה. כי לספיד יש value, ובבדיקות גם יש איזה value, אז אפשר פשוט לעשות המון המון בקשות לוקאלית, אפשר לחבר את זה לסדרת staging, להקליט את הכול. סדרת staging זה סדרת בדיקות שכל ה-R&D משתמש בה, שיותר דומה לסדרת production. אז אפשר להריץ המון המון המון בדיקות, ואז פשוט להריץ את הכלי, זה משווה את הדאטה-בייסים ופשוט מקבלים בחזרה, מקבלים בחזרה את ה-def. וזה פשוט עשה שהסייקלים של הבדיקות שלנו נעשו הרבה יותר מהירות ויכולנו לבדוק הרבה יותר לעומק דברים.

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

אביתר:           כן. יש לזה גם מיטיגציות. אחד הכלים שהשתמשנו בו, זה בסוף, אחריש בדקנו את הכול, כבר היינו די בטוחים בעצמנו, עצרנו ליום שלם של QA של כל ה-R&D על הסדרת staging. כי כאן הרבה דיברנו על data. אבל security זה לא פותר לנו. למרות שה-data הוא אותו דבר, אם הקוד יש לו לוגיקה שונה יכול להיות שזה יתנהג שונה. אז שם ממש פירקנו את המערכת לחלקים. ומי שהכי מומחה בכל חלק עשה ממש בדיקות ידניות. עכשיו, גם את הדברים האלה אפשר לקחת, להקליט, כי זה עבודה  גם ככה אנחנו הולכים לעשות, ולהריץ. ולראות שהדאטה-בייסים הם אותו דבר. אז אפשר גם לחבר את ההקלטות האלה על הסדרת staging מאוד בקלות, בדומה לאיך שמחברים את זה לוקאלית. ולעשות את ההשוואה. יש גם טסטים אוטומטיים שיש לנו שאפשר להקליט. יש לנו, בטסטים יש uni-testing, integration test ו-end to end. ש-end to end זה ממש טסטים שמעלים את ה, כאילו, מדמים את האפליקציה מאפס. כאילו, ממש כמו לקוח. מעלים את ה-browser, נכנסים, מכניסים שם טקסטים. גם אותם אפשר להקליט אוטומטית. אז יש פה הרבה דברים שאנחנו מקבלים חינם. ובנוסף כן, עשינו עבודה ידנית, זה חשוב.

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

אביתר:           לגמרי.

דריה:             אוקיי, אז מה, איזה עוד שלבים עשינו, איזה עוד מנגנוני הגנה השתמשנו בהם?

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

[00:24:00]     וזה יכול לתת לנו שקט, לעשות monitoring, זה לא כאילו, גם אם יש בעיה זה יכול להיות, א' העברנו דרך אגב את ה-account שלנו, שיש לו די הרבה יוזרים ודי הרבה flows שונים.

דריה:             כן, קודם-כל את ה-account של מאנדיי, להתנסות שם, לראות שזה עובד.

עומר:             כן. וגם אחרי זה, אז יכולנו להחליט איזה אקאונטים אנחנו מעבירים, באיזה שעות עומס, ואיך אנחנו עושים monitoring. עכשיו, אוקיי, העברנו רק חלק מהאקאונטים. לקחנו את זה שלב קדימה. הגענו למצב שאם לקוח פותח support ticket, ממש ל-CS, כתוב האם הוא עובד ב-rails ישן או חדש. וכל ה-CS ידעו שאם יש באג עם ה-framework החדש, בגרסה החדשה, ישר להגיד לנו. היינו על זה מאוד מאוד מאוד aligned כאילו איתם ביחד, זה היה מדהים כאילו, שלא משנה מה עלה, אפילו זה false positive, יש אמרו לנו, "נפתח ticket על זה וזה, ואם זה הגרסה החדשה.

דריה:             איך עשיתם את זה? כאילו-

עומר:             זה, מה שעשינו זה, אנחנו עובדים עם Zen desk ב-CS. אנחנו בעצם, יש לנו, בעזרת big brain, שאני מבין שכבר רוב מי ששומע את הפודקאסט כבר מכיר4, המערכת הפנימית שלנו, אז הוספנו איזו מערכת תיוגים, שאפשר לעשות תיוגים על account מסוים, וכל התיוגים האלה מופיעים גם בתוך ה-Zen desk. אז פשוט הוספנו תיוג, framework חדש, וזה הופיע להם.

אביתר:           הפיצול בין האפליקציות, היכולת להעביר אקאונטים, זו עבודה לא טריוויאלית. ששם גם דוד מהאינפרה עזר המון. בסוף אצלנו account הוא… כן, אם זה ממש חברה או חשבון שמשתמש במאנדיי, הוא מוגדר לפי ה-sub domain שלו. או ה-slug. זה אומר ש-monday.monday.com זה ה-account שלנו, ואיזשהו משהו אחר נקודה מאנדיי נקודה קום זה account אחר.

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

אביתר:           בדיוק. אז על ה-sub domain האלה אנחנו בעצם שמנו רולים ב-cloud flare, שבעצם לאיזו סביבה הם הולכים. ואז אני יודע שכל מה שהולך מה-sub domain הזה יגיע לגרסה כזאת וכל מי שהולך מה-sub domain אחר מגיע לגרסה אחרת. זה רק שלב ראשון, כי המערכת היא מורכבת. יש לה הרבה סוגים של שרתים. סתם לדוגמה, יש לנו שרתים שעובדים לעבודות א-סינכרוניות. מה זה אומר? אני רוצה לשלוח מייל כי מישהו עשה log in, אני לא אעשה את זה סינכרונית תוך-כדי הריצה כי זה מעייף אותי, אני כותב את זה לאיזשהו תור והתור מריץ את זה בזמנו החופשי, מכונות אחרות. כל הדבר הזה יושב מעל רדיס, שזה כזה database. אז מה שעשינו, היינו צריכים לפצל את התורים. מה זה אומר? תור שנכתב ב-rails החדש יטופל ע"י מכונה ב-rails החדש. תור שנכתב ע"י ה-rails הישן יטופל ע"י מכונה ב-rails הישן. עכשיו, זה לא מאוד קשה לעשות את זה בקוד, אבל הלהבין את זה היה חשוב אני חושב. ואז זה אומר שיש לנו הפרדה מלאה.

דריה:             ואז מה המשמעות של זה, איך זה עזר לכם?

אביתר:           כרגע שחשבון של מאנדיי, אחרי שאתה כבר logged in ובפנים, אני יודע שאני רץ לחלוטין בגרסה החדשה של rails. זה אומר שאם אני לא מקבל מייל, אני לא מקבל נוטיפיקציה, איזשהו duplicate board, איזושהי פעולה ארוכה א-סינכרונית לא עובדת, אני יודע שזה בעיה ב-rails החדש-

דריה:             אתה יודע לזהות את הבעיה.

אביתר:           בדיוק. ואני יודע ישר לתקוף את זה. וזה מאוד עזר לנו. זה השאיר את העניין על סאב-דומיינים שהם משותפים לכולם. שיש כמה דוגמאות כאלה, כמו לדוגמה API. כל הקריאות API הולכות ל-api.monday.com. או ה-log in הראשי, שזה oaf.monday.com. שזה בעצם מין sub domains שמורים. וכדי לפתור את זה, כדי ממש לפתור, לבדוק flow מלא ב-production, מה שאפשר לעשות זה להוסיף header. שאפשר להגדיר בבראוזר שהוא תמיד יוסיף איזשהו header, ואז אנחנו אומרים, אם יש את ה-header הזה תמיד  תלך על סביבה חדשה. וככה בעצם יכולנו גם לבדוק flow מלא של log in לדוגמה, בגרסה של ה-rails החדש ו-production.

[00:28:00]

עומר:             אני אוסיף שגם בדיקות ידניות עשינו המון, בכל ה-flows המרכזיים וגם הלא מרכזיים, של יצרתי משהו ב-framework הישן, הלכתי ל-framework החדש, קראתי את אותו מידע, שיניתי אותו, החזרתי שוב את ה-account שלי, הלוקאלי, ל-framework הישן, וראיתי שאני מצליח לעבוד על זה. בעצם הקווים אחורה-קדימה, רצינו שיהיה לנו ביטחון של מאה אחוז של-flows העיקריים בטוח אפשר לעבור קדימה ואחורה כמה שרוצים. ואז למשל גם אם ה-API עדיין עובד על ה-framework הישן אבל ה-account עבר ל-framework החדש, זה בסדר, זה אותו data, הוא רשום באותה צורה ב-database, וזה ממש לא הלחיץ אותנו החלק הזה.

דריה:             עם עולה איזושהי בעיה אז תמיד אפשר לחזור אחורה, לתקן ולהמשיך הלאה.

עומר:             אבל אני כן אגיד שהיה לנו מאוד חשוב לבדוק את זה, כי סתם, נגיד מה שאפשר לא לחשוב עליו, נגיד איכשהו ה-sessions ייראו אחרת. פתאום נעביר מישהו, פתאום כל היוזרים יהיו locked out, דברים כאלה. אז גם, נגיד וזה היה קורה – למרות שבדקנו ווידאנו שזה לא קורה – אז גם זה היה קורה ל-account שלנו בבדיקה הראשונה. או נגיד זה לא היה קורה ל-account שלנו אז לאקאונטים הבאים שהיינו מעבירים. אז זה מתחבר ביחד עם זה שאנחנו עושים את הכול כמה שיותר gradual.

אביתר:           אם שוב נדבר על ה-data, נדמה לי שאנחנו מדברים עליו הרבה, אבל הוא באמת החשש הכי גדול שלנו. אנחנו צריכים להבטיח שאין לנו data loss. אז סבבה, עשינו את ה-rack play, הוא באמת מקטין את הסיכונים. ועדיין, מה אם כן יקרה? כאילו, כי פספסנו משהו, כי, כמו שאמרת, עשינו בדיקות ידניות, הכנסנו דברים, ה-flows של כל המאות-אלפי לקוחות שלנו יותר מסובכים ממה שאנחנו עשינו. אז איזה כלי אפשר לעשות שבעצם יקטין עד לאפס את הסיכוי ל-data loss? שאין מצב שמישהו איבד data מכל באג שהוא.

עומר:             כן, זה עלה באחת הישיבות שעשינו כזה synch על למזער סיכונים. ואז עלה לנו רעיון, שבעצם כל מידע שמשתנה ב-database, ממש, כי בסוף ה-database זה טבלאות עם שורות, כל שורה שמשתנה גם נתעד איך השורה הזאת הייתה לפני השינוי. אמרנו "וואו, זה המון מידע לשמור, זה scale מטורף." אז אני ומיטלמן לקחנו את זה, דניאל מיטלמן מהצוות של האינפרה, של דוד. ופשוט היינו איזה יומיים כזה בחדר, הסתגרנו, אמרנו חייבים את הכלי הזה, הוא ייתן לנו מלא ביטחון, וממש לא רצינו גם להעמיס על ה-database הקיים, רצינו שיהיה לנו monitoring, כי זה באמת, מבחינת ה-scale ועומס על ה-database ה-overhead שזה מוסיף לו, לא ידענו גם איך המערכת תתמודד עם זה ב-production, קשה לצפות את זה. אז יצרנו database חדש, שהוא כתוב בצורה מאוד מאוד גנרית. כזה, זה נגיד הטבלה שאני מגבה, זה ה-ID של השורה, ואז יש עוד מין כזה ג'ייסון ענק של כל התוכן של השורה – לא משנה איזה עמודות היו לטבלה המקורית.

דריה:             זאת אומרת שזה הרבה פחות מפורט מה-database הרגיל.

עומר:             כן, מבחינת ה-structure של הטבלה, זה לא שלכל טבלה עשינו טבלה שמגבה את אותה טבלה. יש טבלה גנרית לגבות את הכול, זה הרבה יותר קל לנהל את זה. עכשיו, יש כל-מיני עמודות שרצינו, אנחנו עומדים לשמור שם המון data. צריך שגם יהיה ריאלי לשלוף אותו בזמן סביר במידת הצורך. אז היה לנו חשוב לשים אינדקס. הנה, למשל על זמן, על account ID, שנגיד אוקיי, העברנו account, החזרנו אותו, יש איזה בעיה, איך אפשר מהר לשחזר את הדאטה עבור אותו account. זה היה מאוד חשוב לנו, וגם עשינו על זה ממש אחרי זה, כאילו, ניסינו את זה, בדקנו שזה עובד ממש. אז בסוף מה שעשינו, פשוט גרמנו לזה לקרות, וכל המידע ממש היה מגובה, עוד מלפני שהתחלנו להעביר אקאונטים, כבר הדלקנו את זה, ראינו שהמידע מתעדכן, ניסינו גם לשחזר מידע, ראינו שזה אפשרי. ורק אחרי שממש כל המידע גובה – וצריך להבין זה…

[00:32:00]     נגיד יש לי, אני משנה את הסטטוס, משנה אותו שוב, משנה אותו שוב, אז בטבלה הזאתי כל השורה של ה-items, איפה ששמור המידע של הסטטוס, הייתה מגובה, מגובה, מגובה. אז שיניתי עשר פעמים סטטוס-

דריה:             כל שינוי הכי קטן מגובה.

עומר:             כן, גם אם ב-database המקורי זה עדיין שמור פעם אחת אז שם זה יהיה שמור עשר פעמים.

דריה:             וזה ב-data של כל הלקוחות?

עומר:             כן. עכשיו, היה לנו איזה סיפור מעניין, שביום שהעברנו את ה-account שלנו, נורא התרגשנו, שמחנו, הכנו את כל המנגנונים. פתאום מישהו אומר "נעלמו לי כל האייטמים מהבורד." מה, זה, היה לנו ברור ש… לחץ מטורף, אדרנלין. החזרנו את ה-account. מסתכלים, ה-data נעלם. כאילו, מהבורד. אחרי כל הבדיקות שעשינו. היה איזה תיקון של משהו שהעלינו ברגע האחרון, כאילו, ברגע האחרון, זה פשוט עלה באותו יום, אבל היה שם איזו טעות. וזה גרם לזה. משהו שקשור לשדרוג. אז א' תפסנו את זה מאוד מהר. בגלל כל העניין של ה-gradual release. דבר שני אמרנו "טוב, בואו נבדוק את המנגנון." תוך רגע הצלחנו לשחזר את כל המידע שנעלם. וזה היה מדהים, וזה נתן לנו גם ביטחון על הכלי, ואז כמובן תיקנו את הבאג הזה וחזרנו שוב ל-release.

דריה:             מדהים.

אביתר:           הייתי שמח גם להסביר שנייה על הבאג הזה, כי אנחנו מדברים על הרבה דברים תאורטיים של באגים שיכולים לקרות. אז בלי להיכנס יותר מדי ל-details, מה קרה פה? היה לנו מנגנון cashing. מנגנון cashing זה שאנחנו שומרים את ה-data באיזשהו database אחר לשליפות מאוד יעילות, כדי לטעון דברים מהר. כי המערכת היא ב-scale גבוה. כאילו, אני מניח שלרוב מי ששומע את הפודקאסט הזה יש מנגנוני cashing כאלה או אחרים. אם הייתם עושים cash בגרסה הישנה של rails ומעדכנים אותו בגרסה החדשה ואז שומרים, ה-data מה-cash היה מתפרסר בצורה לא נכונה, ואז אחרי השליפה והשמירה זה היה בעצם מוחק את הרשומות כי זה היה חושב שהן לא היו קיימות מלכתחילה. וזה פשוט דברים שכאילו, בלי המנגנונים האלה ובלי הבדיקות ובלי ההרצות, מאוד מאוד קשה להגיע אליהן. קשה מאוד לכתוב לזה טסט, end to end או מיני-טסט או כל דבר. וזה בדיוק ה-flows שרצינו להגן, וזה באמת בעיה אמיתית, שתפסנו אותה בזמן, ואצלנו, בלי שזה פגע באף לקוח. [מוזיקה]

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

אביתר:           אז כל השלבים הראשונים, כל השלבים שעובדים יש לחץ, יש כאילו, רוצים להספיק את זה בזמן, כאילו, רוצים להתקדם. אבל זה בקטנה. יש את השלב הזה שזה עולה ל-production, אוקיי? וכאן יש המון סיבוכים. כי קודם-כל עבר גרסה חדשה, אבל יש לנו שתי גרסאות רצות. זה אומר שה-deployment, אם עושים deploy חדש הוא עושה שתי deployments, לגרסה הישנה ולגרסה החדשה. אם מישהו, כל אחד ב-R&D רוצה עכשיו לכתוב קוד ולהעלות אותו, הוא צריך להעלות אותו בשתי הגרסאות. עכשיו, זה friction שרצינו לא לעשות לאנשים. אז בסופו של דבר, אני לא זוכר בדיוק, אבל יומיים שהיינו בלי deployments שהם לא חירום.

אט:                מה זה אומר?

אביתר:           שהאנשים שעובדים על פיצ'רים צריכים לחכות יומיים ולא להעלות קוד חדש.

דריה:             אוקיי, אתם אומרים לכל ה-R&D אתם עכשיו לא מעלים קוד חדש.

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

[00:36:00]     ומצאנו באגים, היו כמה באגים שפספסנו. מה שכן, זה באגים קטנים. היה איזה flow צדדי כזה שאף אחד לא זכר שבכלל קיים במערכת, שנפל. והיינו מאוד ב-drive של, כאילו, אנחנו יכולים לחזור אחורה, יש לנו את המתג, לוחצים עליו והכול חוזר אחורה, ואנחנו לא רוצים. אנחנו גורמים לדבר הזה לעבוד, זה ה-conviction שצריך כדי להרים דבר כזה. לא רצינו לחזור אחורה, אנחנו יכלנו בכל שלב, אבל אנחנו רוצים לגרום לדבר הזה לעבוד, אנחנו רוצים לדחוף את זה עד שזה יקרה.

דריה:             אם יש בעיה מתקנים וישר ממשיכים הלאה.

אביתר:           מתקנים. היינו כאילו, שלושתנו, ארבעתנו, עוד כמה אנשים הצטרפו שם, בטירוף. מוצאים איזה באג, מוצאים איזה error קטן, מתקנים. פותחים לעוד לקוחות, רואים שלא נפתחים טיקטים. פתאום קופץ איזה משהו, יש איזו בעיה ב-time zones. פתאום לאיזה לקוח הבורדים לא נפתחים. ישר בודקים, שזה לא security, שזה לא data loss, מתקנים את הבאג בעוד deploy, בשתי הגרסאות, רואים שאנחנו תמיד עדיין יכולים לחזור אחורה, אבל שאנחנו גם תמיד תמיד מתקדמים. וזה היה – אני לא זוכר בדיוק כמה זמן לקח כל ה-process של ה-release, כמה ימים – מאוד אינטנסיבי. מאוד מאוד אינטנסיבי [צוחק], שפשוט דחפנו, מתקנים מתקנים מתקנים, המון המון המון דברים קטנים, כדי שהמערכת תעבוד. ואז גם אחרי שהעברנו את כל הלקוחות, עדיין השארנו את הגרסה הישנה למעלה לעוד כמה ימים. אמרנו כאילו סבבה, העברנו את כולם, אנחנו חושבים שהכול טוב, ומה אם? אז חיכינו. ועדיין יש את הגרסה החדשה, אבל כבר לכל ה-R&D עובדים בגרסה החדשה, ה-deployments הם בגרסה החדשה, זה כבר העיקרי, ואנחנו מתחזקים את הישנה בתור fall back כל הזמן.

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

עומר:             כן. בנוסף לזה, רצינו אבל כן לקבל פידבק. כאילו, לא רצינו, הרי לא רצינו גם להעביר את זה ב-rush hour וכו'. אז מה שעשינו, השתמשנו ב-big brain, ויש לנו, בעזרת כלים של big brain יכולנו לזהות איזה לקוחות הם יותר פעילים דווקא בשעות הפחות פעילות של רוב הלקוחות. ואז יכולנו להתחיל להעביר אותם קודם ולדעת שהם עובדים על המערכת, וגם אם יש בעיה אז הם ידברו עליה. כי סתם, נגיד אצלנו רוב ה-traffic בשבוע הוא בין שני לחמישי בערב. ובשבת וראשון יש פחות traffic. ודווקא זה זמן טוב להתחיל משהו שהוא קטן. אבל, אז נגיד מעבירים לקוח בראשון בבוקר, זה לא יעזור אם הוא בכלל לא עובד על המערכת בראשון בבוקר. אז בראשון העברנו את הלקוחות שהם הכי פעילים בראשון. וככה גם כל ההמשך, וגם יש פה איזה עניין שמתחילים עם מעט אבל ככל שפותחים ליותר לקוחות אז כבר באחוזים כל פעם פותחים ליותר ויותר. כאילו, גם אם נתחיל לעשרה ואז למאה ואז לאלף ואז לעשרת אלפים, וכאילו ככה ממש לאט לאט זה עולה בצורה אקספוננציאלית.

דריה:             אביתר, אתה הזכרת שהיה יום אחד שביקשתם מכל ה-R&D לעשות סוג של Q&A כזה על הפלטפורמה, על השדרוג החדש. היו עוד מקרים שהייתם צריכים את העזרה של שאר המחלקה?

אביתר:           נעזרנו באנשים ספציפיים על פיצ'רים ספציפיים, כמובן, כן? לא עובד משהו במיילים, אז מי שכתב אני ישר בא, יושב איתו – כשהיינו כולם במשרד – ופותרים את זה ביחד. אבל אנחנו מאוד מאוד ניסינו שהאימפקט ה… להאט את ה-R&D כמה שפחות. כי אני חושב שמה שממש יפה במה שעשינו זה ששלושה אנשים היו dedicated ולרוב האנשים זה לא השפיע המון. נקודות שזה השפיע על החיים של כולם בצורה ברורה, אז אחת זה כמובן היום הזה שלקחנו את כל ה-R&D לבדיקות. הדבר השני זה מה שדיברנו שאי אפשר היה לעשות deployments ליומיים-שלושה, זה מסבך, כי אנחנו כן מאוד אוהבים שהגרסאות שלנו הן up to date כל הזמן.

[00:40:00]     והנקודה השלישית שגם היינו צריכים להתעסק איתה, אנחנו עובדים על איזושהי סביבה, ועכשיו באיזשהו שלב כולם צריכים לשדרג אותה. כי כולם עבדו על הסביבה הישנה. ועכשיו באיזשהו יום, אוקיי, מעכשיו סביבה חדשה, זה ה-source of truth, זאת האמת. וגם שם התאמנו קצת על אנשים לפני, לראות שזה עובד, לראות שכאילו… כי להרים את הסביבה בהתחלה זה היה המון עבודה ידנית והמון סיבוכים. ואחרי שאנחנו כבר רוצים שכולם יעשו את זה, אנחנו רוצים שזה יהיה יעיל, שזה יהיה קל. ושאנשים, כאילו, שנוכל לעשות את זה מהר. אז גם על זה כזה התאמנו לפני וגם עצרנו את כולם והתקנו את זה כזה ביחד וראינו שזה עובד, ולכמה אנשים זה לא עבד כמובן, ורצנו לתקן.

דריה:             כן, זה יחסית לרוץ על זה גם, בצורה שהיא מאוד lean. שהיא סוג-של כמו שאר המחלקה של R&D, שמנסים לעשות דברים lean, אז גם כאן, למרות שזה היה תהליך שהוא מאוד כבד סך הכול, הוא מאוד מאסיבי, בסוף זה התמקד בעבודה מאומצת של שלושה-ארבעה אנשים.

אביתר:           כן. דוגמה על ה-staging. לפני ש, זה היה אחד השלבים האחרונים שעשינו. למה זה? כי אם לדוגמה עושים את זה מוקדם מדי וה-log in לא עובד, אז אנחנו עוצרים את כל ה-R&D, אף אחד לא יכול לעשות log in, כולם תקועים. ואנחנו מחכים שאנשים יבדקו דברים וכולם מחכים לנו שנתקן איזה באג כדי שיוכלו להתקדם. או אי אפשר ליצור בורדים, או דברים בסיסיים במערכת, אם דברים בסיסיים לא עובדים אין מה לעצור את כולם ולבדוק, בוא נבדוק ידנית, בוא נתקן, בוא נראה שהמערכת יציבה, מרגישה טוב. ואז נשתמש במוח של כולם, עם הבנה עמוקה בפיצ'רים, לבדוק את כל ה-flows בצורה שהם יודעים לעשות הכי טוב. וזה מקבל את ה-added value האמיתי, לא שכולם יבדקו את אותו דבר שאנחנו יכולים לעשות בעצמנו.

דריה:             מדהים. יש זמן נכון לעשות שדרוג כזה לחברה? יש זמן נכון, יש זמן לא נכון?

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

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

עומר:             נכון.

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

אביתר:           אם נחזור לשיקולים שאמרנו בהתחלה ללמה עשינו את זה בכלל, אז יש את השיקול של ה-security. יש איזשהו שלב שפריימוורקים ושפות תכנות מפסיקים לקבל security patches. בעצם מגיעים ל-end of life. שזה שלב שצריך לשדרג לפניו. כי ברגע שעושים את זה, אז אנחנו עכשיו פגיעים. כי אף אחד לא מאתר את הדברים הלאה, אנחנו לא מקבלים פה תיקונים. כשה-minor patches מפסיקים לצאת זה אומר שיכול להיות שיש איזו פרצה חדשה שמישהו גילה ואף אחד לא מתקן אותה בגרסה שאנחנו רוצים, אפילו לא נשמע עליה. כי זה כבר לא מתוחזק. מהכיוון השני, מה שדיברו על הפקג'ים ועל ה-open source, כשעובדים עם גרסאות ישנות אז זה מאט את הפיתוח. אוקיי? כי בסוף אתה בא להכניס משהו חדש ומגניב והוא לא עובד. אתה צריך להשתמש במשהו ישן ודרעק כדי שזה יעבוד, כשאתה יודע שתצטרך לשדרג אותו אחר-כך. אבל גם אחרי שאמרתי את כל זה זה… זה הכי קל, כן? להגיד "כן, צריך לשדרג וזה" וישר… זה קשה. זה קשה. חשוב לדעתי לתכנן את זה הרבה זמן לפני.

[00:44:00]     כי לבוא באיזשהו איטרציה או רבעון ולהגיד "אוקיי, עכשיו צריך לעצור הכול, לקחת אנשים מאוד ספציפיים לעשות מאמץ אינטנסיבי על זה" זה מאוד קשה. מצד שני אנחנו יודעים את ה-end of life האלה, אנחנו יודעים את השדרוגים, אז שווה לתכנן את זה חצי שנה-שנה קדימה. כל הזמן כאילו… כי בפרויקטים כאלה זה הרבה יותר קל. כשאנחנו מדברים על זה כבר חצי שנה מראש, שנה מראש, להקצות לזה את המשאבים, להבין שזה נכון או לא נכון לתקופת זמן ההיא – זה מאוד מאוד עוזר. הכי גרוע זה פתאום, לקום יום אחד ולהגיד "הבית עולה באש". ואז כאילו עושים דברים לא טוב. אז התכנון קדימה פה לדעתי הוא סופר-חשוב.

דריה:             טיפים אחרונים למי שרוצה עכשיו לגשת לתהליך הזה ולא כל-כך יודע מאיפה להתחיל, אז מה הדבר הכי חשוב שצריך לשים עליו דגש?

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

אביתר:           אני גם אביא לזה אקסטרה-דגש. כשאתם עושים דברים שלא עובדים כמו שה-framework בנוי, כשעושים קומבינות, כשמעקמים דברים – אנחנו עשינו הרבה קומבינות. כי ככה גורמים לדברים לעבוד. אז הכי חשוב לכתוב להם טסטים. כשעושים משהו שהוא custom, כשאתם דורסים את ה-class הבסיסי בפנים של active record, ברגע שאתם עושים את הדברים האלה, זה חייב להיות tested, כי זה דברים שיישברו ואף אחד לא יתעד אותם, כי זה ממש business logic פנימי שלנו. אז זה דבר אחד. והדבר השני שהייתי אומר שהוא הכי חשוב, זה השילוב הזה בין הגישה של להיות זהירים ל-drive הזה, לזה שזה הולך לקרות. כי בין הלא לעשות לפשוט לעשות ולקוות לטוב, אז השילוב, החלק המעניין, אנחנו הולכים לעשות את זה ואנחנו הולכים לעשות את זה טוב. זה קשה, אבל זה אפשרי, ופשוט עם ה-mindset הזה לדעתי ממש אפשר להצליח.

דריה:             לגמרי. אני חושבת שבאופן כללי ובמאנדיי ספציפית יש את הגישה הזאת של כזה בואו נרוץ ונתקן תוך-כדי שדברים קורים. אז דווקא כאן זה מקרה מובהק של "לא, בואו נעצור ונתכן כמו שצריך." נחשוב קדימה, ונגרום לתהליך שעל-פניו נראה שהוא מאוד מסוכן, נגרום לו להיות הכי חלק שאפשר. וזה משהו די מדהים לחשוב עליו שבאמת אפשר לגרום לזה לקרות ככה. ושאפשר באמת להחליף גלגל למכונית בזמן שהיא נוסעת [צוחקת], זה גם משהו שאני למדתי היום.

עומר:             לגמרי. אני רוצה להוסיף עוד טיפ. הרבה פעמים כשמשדרגים אז, לא משנה אם זה הגרסאות של ה …[ל.ב]  או של ה-framework, אז אומרים "אה, מהגרסה הזאתי זה צריך להיות כתוב ככה, אבל בגרסה הקודמת זה היה כתוב ככה." עכשיו, אם זה לשנות שורה, אז כמובן לשנות אותה ולגרום לזה לעבוד. אבל אם פתאום עכשיו צריך לשנות אלף קבצים? יש פה risk מטורף, אפילו אם אני אעשה typo באיך שאני משנה את הקובץ או שיש איזה flow שנשבר ואין לי טסט שמכסה אותו. אז לפעמים אפשר לכתוב קוד שלנו או לראות אם אפילו יש איזה, מישהו כבר הוציא איזה jam שאומר אפשר לשדרג אבל עדיין להשתמש עם זה איך שזה היה כתוב קודם. לפעמים צריך לדרוס איזה class ולתמוך בזה. אז נראה לי החוכמה זה לשדרג את הגרסה אבל להימנע משינויי קוד גדולים. כאילו, אם אני, מתי רואים את זה? נגיד מתחילים לשדרג, אז אומרים "טוב, יש לי פה שינוי, אה, רגע, אני צריך לעשות פה עכשיו את השינוי הזה באלף קבצים, במאה קבצים", אני אומר "רגע רגע, בוא נבדוק אם אפשר לא לעשות את זה בגרסה החדשה." ואם אפשר אז לא לעשות את זה.

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

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

דריה:             עוד משהו?

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

[00:48:00]

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

אביתר:           תודה.

דריה:             תודה עומר.

עומר:             תודה.

דריה:             תודה שהאזנתם. ביי. [מוזיקה]

 

 

 

 

הניוזלטר שלנו

הירשמו וקבלו עדכונים על פרקים חדשים, כתבות, אירועים ועוד הפתעות!

רוצים לקחת חלק בשיתוף ידע?

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

iconתשאלו אותנו הכל