שיטות עבודה מומלצות של DevOps למפתחים. אנטון בויקו (2017)

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

הרשו לי להציג את עצמי, אני מודה בפה מלא שיש אנשים בחדר שלא מכירים אותי. שמי אנטון בויקו, אני MVP של Microsoft Azure. מה זה MVP? זהו Model-View-Presenter. Model-View-Presentator זה בדיוק אני.

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

כמה מילים על עצמך:

• אני עוסק בתחום הזה כבר 10 שנים.
• עבדתי במיקרוסופט.
• אני האב המייסד של קהילת התכלת האוקראינית, שהקמנו אי שם ב-2014. ועדיין יש לנו את זה ואנחנו מפתחים את זה.
• אני גם אביו של מייסד כנס Azure, שאנו מארחים באוקראינה.
• אני גם עוזר לארגן את ה-Global Azure Bootcamp בקייב.
• כמו שאמרתי, אני MVP של Microsoft Azure.
• אני מדבר בכנסים לעתים קרובות למדי. אני מאוד אוהב לדבר בכנסים. בשנה האחרונה הצלחתי להופיע כ-40 פעמים. אם אתם עוברים ליד אוקראינה, בלארוס, פולין, בולגריה, שוודיה, דנמרק, הולנד, ספרד או נותנים או לוקחים מדינה אחרת באירופה, אז בהחלט ייתכן שכשאתם הולכים לכנס שיש לו נושא ענן בזרם, אולי תראה אותי ברשימת הדוברים.
• אני גם מעריץ של מסע בין כוכבים.

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

• נדבר על מה זה DevOps. בואו נדבר למה זה חשוב. בעבר, DevOps הייתה מילת מפתח שכתבת בקורות החיים שלך ומיד קיבלת +$500 משכורת. עכשיו אתה צריך לכתוב, למשל, בלוקצ'יין בקורות החיים שלך כדי לקבל +500 דולר למשכורת שלך.
• ואז, כשנבין קצת מה זה, נדבר על מהן שיטות DevOps. אבל לא כל כך בהקשר של DevOps באופן כללי, אלא על אותן שיטות DevOps שעשויות לעניין מפתחים. אני אגיד לך למה הם עשויים לעניין אותך. אני אגיד לך למה אתה צריך לעשות את זה בכלל ואיך זה יכול לעזור לך לחוות פחות כאב.

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

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

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

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

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

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

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

כשאתה מתחיל ליישם תרבות DevOps, חשוב מאוד שהיא תיושם בסדר הבא.

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

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

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

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

מה הכי רוצה QAS? אני לא יודע אם הם באולם. קשה לי לומר שאני רוצה QA, כי אף פעם לא הייתי כזה. ולא להעליב את החבר'ה, ייאמר שאני מקווה שלעולם לא אעשה זאת. אבל לא מהסיבה שאני מחשיב את עבודתם חסרת משמעות וחסרת תועלת, אלא בגלל שאני לא מחשיב את עצמי כאדם שיכול לעשות את העבודה הזו ביעילות, אז אני אפילו לא אנסה לעשות את זה. אבל ממה שהבנתי, מה ש-QA לא הכי אוהב זה ללכת לעבוד בבוקר, להריץ כל הזמן סוג של מבחני רגרסיה, לדרוך על אותם באגים שדיווחו למפתחים לפני 3 ספרינטים ולומר: "מתי תצליחו , מסייה ד 'ארטניאן, תקן את הבאג הזה.' ומסייה ד'ארטניאן עונה לו: "כן, כן, כן, כבר תיקנתי את זה." ואיך קורה שתיקנתי באג אחד ועשיתי 5 בדרך.

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

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

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

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

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

בואו נדבר על שיטות DevOps באופן כללי. מה הם? מה ההבדל? איך לנסות אותם? למה הם חשובים?

התרגול הראשון שאולי שמעתם עליו נקרא אינטגרציה מתמשכת. אולי למישהו בפרויקט יש אינטגרציה מתמשכת (CI).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

נתחיל במשהו פשוט. לדוגמה, הם שכחו לשים CSS בארכיון או שכחו לשנות את ההאשטאג בשם קובץ ה-java-script. וכשאנחנו מגישים בקשה לשרת, הדפדפן חושב שכבר יש לו את קובץ ה-Java-script הזה ומחליט לא להוריד אותו. והייתה גרסה ישנה, ​​משהו היה חסר. באופן כללי, יכולות להיות הרבה בעיות. לכן, התרגול של Continuous Deployment מאפשר לך לפחות לבדוק מה יקרה אם היית לוקח תמונת הפניה נקייה ומעלה אותה לסביבה חדשה נקייה לחלוטין. אתה יכול לראות לאן זה מוביל.

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

אחת הבעיות שמתרחשות כאשר נעשה שימוש רב ב-vanilla java-script היא ששני מפתחים הכריזו בפזיזות על משתנה בעל אותו שם באובייקט החלון. ואז, תלוי במזל שלך. מי שקובץ ה-Java-Script שלו נשלף שנית יחליף את השינויים של השני. זה גם מאוד מרגש. אתה נכנס: דבר אחד עובד עבור אדם אחד, דבר אחר לא עובד עבור אחר. וזה "נפלא" כשהכל יוצא בהפקה.

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

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

אבל הבעיה הייתה אחרת. כאשר פרסנו גרסה חדשה של אתר ה-php שלנו, איך פרסנו אותה? לרוב פתחנו את Far Manager או משהו אחר. והעלה את הקבצים האלה ל-FTP. ופתאום הבנו שיש לנו איזה באג קטן וקטן, למשל, שכחנו לשים נקודה-פסיק או שכחנו לשנות את הסיסמה לבסיס הנתונים, ויש סיסמה לבסיס הנתונים, שנמצאת על המארח המקומי. ואנחנו מחליטים להתחבר במהירות ל-FTP ולערוך את הקבצים ממש שם. זו רק אש! זה מה שהיה פופולרי בשנות ה-90.

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

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

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

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

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

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

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

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

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

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

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

כשאנחנו מדברים על תשתית וירטואלית, אנשים רבים חושבים שזה משהו שמנהלים מגדירים. ואם אתה צריך, נניח, להשיג שרת חדש שבו אתה רוצה לבדוק גרסה חדשה של האפליקציה שלך, אז אתה חייב לכתוב כרטיס למנהלים או ל-devops. ל-Devops ייקח 3 שבועות בשביל זה. ואחרי 3 שבועות יגידו לכם שהתקנו עבורכם מכונה וירטואלית, עם ליבה אחת, שני גיגה-בייט RAM ושרת Windows ללא DotNet. אתה אומר: "אבל רציתי דוטנט." הם: "בסדר, תחזור בעוד 3 שבועות."

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

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

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

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

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

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

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

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

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

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

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

ניהול תצורה. ייתכן שיש לנו תצורות שונות בסביבות שונות. לדוגמה, ייתכן שיש לנו כניסות וסיסמאות שונות עבור מסדי נתונים עבור QA, הדגמה, סביבת ייצור וכו'.

תצורה זו יכולה להיות גם אוטומטית. זה תמיד צריך להיות נפרד מהאפליקציה עצמה. למה? בגלל שבנית את האפליקציה פעם אחת, ואז לא אכפת לאפליקציה אם אתה מתחבר לשרת SQL דרך IP כזה או אחר או IP כזה ואחר, זה אמור לעבוד אותו דבר. לכן, אם פתאום מישהו מכם עדיין מקדד את מחרוזת החיבור בקוד, אז זכור שאני אמצא אותך ואעניש אותך אם תמצא את עצמך באותו פרויקט איתי. זה תמיד ממוקם בתצורה נפרדת, למשל, ב-web.config.

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

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

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

למה? כמובן, זה יהיה נהדר אם לכל מפתח יהיה מכונה וירטואלית שתעבוד 24/7. אבל אולי זה חדשות בשבילך, אולי לא שמת לב, אבל היזם עצמו לא עובד 24/7. מפתח עובד בדרך כלל 8 שעות ביום. גם אם הוא מגיע מוקדם לעבודה, יש לו ארוחת צהריים גדולה שבמהלכה הוא הולך לחדר כושר. תן לזה להיות 12 שעות ביום כשהמפתח באמת משתמש במשאבים האלה. על פי החקיקה שלנו, יש לנו 5 מתוך 7 ימים בשבוע שנחשבים לימי עבודה.

בהתאם לכך, בימי חול המכונה הזו לא אמורה לעבוד 24 שעות, אלא רק 12, ובסופי שבוע המכונה הזו לא אמורה לעבוד כלל. נראה שהכל מאוד פשוט, אבל מה חשוב לומר כאן? על ידי יישום תרגול פשוט זה בלוח הזמנים הבסיסי הזה, הוא מאפשר לך להפחית את עלות תחזוקת הסביבות הללו ב-70%, כלומר לקחת את המחיר של המפתח, ה-QA, ההדגמה, הסביבה וחילקת אותו ב-3.

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

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

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

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

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

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

הבנתי, תודה!

אם לא יהיו שאלות, אני חושב שנוכל לסיים. תודה!

מקור: www.habr.com