רברס עם פלטפורמה על פריסה ממשכת (הפודקסט)

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

בקרת איכות ידנית היא שורש כל רע

ראשית עלינו להבדיל בין בקרת איכות - QA, לבדיקות קבלה (Acceptance Test). 

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

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

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

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

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

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

מצגת על פריסה ממשכת

בביקורי האחרון בישראל זכיתי להתארח במעבדות המחקר של יבמ, Outbrain וAnswers.com. בביקור הצגתי את עקרונות הפריסה הממשכת והמימוש בקצ'ינג בעזרת מצגת Prezi.

Continuous Deployment on Prezi

ארבעה שלבים חיוניים בראיון עבודה למשרת תכנה

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

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

ראיינתי מאות מהנדסים לחברות בכול הגדלים, להלן המתכון המנצח:

1. סינון טלפוני מהיר (עשר דקות): בחרת מועמד מערמת קורות החיים, איש כוח האדם או אתה תדברו עם המועמד, ספרו לו בקצרה על מה מדובר ותגידו לו שתשלחו לו חומר נוסף באמייל. תכינו שלוש עד חמש שאלות פשוטות הדורשות תשובה פשוטה ותשאלו את אותם השאלות. למשל: כמה זה שתיים בחזקת עשר, האם "Hash Code" הוא ייחודי בHashMap וכיוצא בזה. כבר כאן הרוב נופלים.

2. שיחה טלפונית שנייה (30 דקות): שניכם ליד מחשב משתמשים באתר עריכה שיתופי כגון PiratePad. יש להכין מראש שלוש שאלות כל אחת אמורה לקחת חמש עד עשר דקות. אם היא לוקחת יותר מעשר דקות, להמשיך הלאה. כדאי שהשאלות יכסו תחומים שונים. אין לצפות שהמועמד ישיב נכון על כל השאלות!

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

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

שאלות נוספות לשאול: איזה קוד פתוח כתבת לאחרונה (להראות את הקוד)? מהנדסים מעולים מתיחסים לתכנה כתחביב ולרובם יש פרויקטים קטנים פה ושם.

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

אם הראיון הראשון היה רע במיוחד או השניים הראשונים בינוניים - לחתוך.

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

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

הרצאה על פריסה ממשכת ביבמ חיפה

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

המצגת תפורסם בבלוג בעוד מספר ימים.

תזרום אחי, תזרום

אהבתי את הציטוט של קנת בק "... כי אפשר לשפוך דלי. אי אפשר לשפוך צינור!" ע"י איתי ממן (בתרגום חופשי, הוצא מהקשרו).

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

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

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

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

פריסת אשכולות בגן חיות

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

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

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

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