RESOURCES

אז מה זה DevOps בתכל’ס? במילים פשוטות: DevOps זה לקחת את אנשי הפיתוח (אלה שכותבים את הקוד ואומרים: “אבל אצלי עובד”) ואת צוותי התפעול (אלה שמסרבים לעלות את קוד אומרים “זה עובד ככה, אל תגע”.) — ולגרום להם לעבוד יחד, אבל באמת.

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

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

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

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

מחזור חיי DevOps — איך זה נראה באמת?

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

תכנון (Plan)
הכול מתחיל בשאלה פשוטה: “רגע, מה אנחנו מנסים לעשות פה?”. כי אם ישר רצים לכתוב קוד בלי להבין את המטרה, זה נגמר כמו פאזל בלי התמונה על הקופסה. אז יושבים, מבינים מה הלקוחות צריכים, מה העסק רוצה, ומוודאים שכולם מדברים על אותו דבר — לפני שמישהו בונה מערכת לאפליקציה שאף אחד לא באמת צריך.
כלים בשימוש: Jira, monday Dev, Confluence, Opentext, IBM

כתיבת קוד (Code)
פה נכנסים לעניינים. המפתחים כותבים קוד, אבל לפי סטנדרטים — לא כל אחד ממציא סגנון משלו. משתמשים ב-Git, עושים סדר, כי אין דבר יותר מלחיץ מ-“מי דרס לי את הקוד?”. קוד איכותי ובטוח – זה מה שמונע סשן תיקונים של שישי בלילה.
כלים בשימוש: Git, Bitbucket, IBM, Okteto, Firefly

בנייה (Build)
הקוד מוכן? יופי. עכשיו מחברים הכול ויוצרים גרסה שעובדת. הכלים כמוJenkins  או CloudBees CI/CD דואגים שזה יקרה, כי לגלות שהקוד “עובד אצלך אבל לא עובד אצלי” זה פחות כיף. זה השלב שבו מגלים אם הצוות באמת עבד מסונכרן — או שצריך סיבוב תיקונים קטן (או גדול).
כלים בשימוש: Jenkins, CloudBees, JFrog, Okteto

בדיקות (Test)
לא שולחים שום דבר לפרודקשן לפני שבודקים אותו מכל כיוון. זה כמו לנסוע לחו”ל ולבדוק שהדרכון בתוקף — חובה. עושים בדיקות קבלה, אבטחה, אינטגרציה וביצועים עם כלים כמו JUnit ו-Selenium. עדיף לתפוס תקלות עכשיו מאשר לראות אותן בסטטוס דרמטי של הלקוחות בלינקדאין.
כלים בשימוש: Snyk, Okteto, Opentext, Klocwork

הפצה (Release)
הבדיקות הסתיימו בהצלחה? מצוין. עכשיו משחררים גרסה. לאט ובזהירות, כי אף אחד לא רוצה להיות זה ששחרר באג לפרודקשן ביום חמישי אחה”צ. הצוות דואג שהכול קורה ובשליטה, ואם צריך — מעלים את העדכונים בצורה הדרגתית, כדי שלא יהיו הפתעות.
כלים בשימוש: CloudBees, JFrog, Quali, Firefly

פריסה (Deploy)
שלב הפריסה — פה לא מאלתרים. משתמשים ב-Infrastructure-as-Code כדי להקים תשתיות ולהעלות גרסאות בלחיצת כפתור. אם מישהו מוצא את עצמו עדיין נכנס לשרת ידנית — משהו פה לא עובד לפי הספר. כל הפריסה צריכה להיות אוטומטית, מדויקת וחלקה.
כלים בשימוש: CloudBees, JFrog, Quali, Firefly

תפעול (Operate)
המוצר באוויר? יופי, אבל זה לא אומר שיושבים רגל על רגל. ממשיכים לתפעל, לבדוק שהמערכת יציבה, שהכול עובד, שאף אחד לא מקבל הודעות שגיאה מוזרות. הכלים כמו Firefly עושים סדר, ואנחנו שומרים שהכול רץ — כדי שאנחנו לא נצטרך לרוץ גם.
כלים בשימוש: Quali, AppDynamics, Jira Service Management, Monday Service

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

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

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

רוצים עזרה לבנות תהליך כזה אצלכם? דברו איתנו 😉 devops@matrix.co.il