האץ את מחזור חיי השחרור עם מסלול לפריסה: חלק 1 - בלוג IBM

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

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

המהות האמיתית של הערך מופיעה כאשר עסקים ו-IT יכולים לשתף פעולה כדי ליצור יכולות חדשות במהירות גבוהה, וכתוצאה מכך לפרודוקטיביות רבה יותר של מפתחים ולמהירות יציאה לשוק. מטרות אלה דורשות א מודל תפעול יעד. פריסה מהירה של יישומים לענן דורשת לא רק האצת פיתוח עם אינטגרציה, פריסה ובדיקות מתמשכות (CI/CD/CT), היא גם דורשת האצת מחזור החיים של שרשרת האספקה, הכוללת מספר קבוצות אחרות כמו סיכון ממשל ותאימות (GRC), ניהול שינויים , תפעול, חוסן ואמינות. ארגונים מחפשים כל הזמן דרכים שיעצימו את צוותי המוצר לעבור מרעיון לפריסה מהר יותר מאי פעם.

גישה של אוטומציה ו-DevSecOps

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

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

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

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

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

נתיב לפריסה: תצוגה ואתגרים נוכחיים

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

האתגרים המרכזיים עם האופי המסורתי של SDLC הם:

1. זמן המתנה לפני הפיתוח של 4-8 שבועות בתוך שלב האדריכלות והעיצוב כדי להגיע לפיתוח. זה נגרם על ידי:
   • סקירות מרובות של מייל ראשון כדי להבטיח שאין השפעות עסקיות שליליות, כולל חששות בפרטיות, סיווג נתונים, המשכיות עסקית ועמידה ברגולציה (ורובם ידניים).
   • תהליכי SDLC כלל ארגוניים שנשארים מפל מים או זריזים למחצה, הדורשים ביצוע רציף, למרות עקרונות זריזים במחזורי פיתוח (לדוגמה, הקצאת סביבה רק לאחר אישור תכנון מלא).
   • יישומים הנתפסים כ"ייחודיים" נתונים לבדיקה מעמיקה והתערבויות עם הזדמנויות מוגבלות להאצה.
   • אתגרים במיסוד ארכיטקטורה ופיתוח מבוססי דפוסים עקב היעדר מאמץ מלוכד והנעת סוכני שינוי, סטנדרטיזציה כזו.
   • תרבות אבטחה המשפיעה על מהירות הפיתוח, תוך הקפדה על בקרות והנחיות אבטחה הכוללות לרוב תהליכים ידניים או חצי ידניים.
2. זמן המתנה לפיתוח לאספקת סביבת ושילוב כלי CI/CD/CT עקב:
   • הקצאת סביבה ידנית או אוטומטית למחצה.
   • דפוסים (על הנייר) רק כהנחיה מרשימה.
   • כלי DevOps מפוצל שדורש מאמץ כדי לתפור יחד.
3. זמן ההמתנה שלאחר הפיתוח (המייל האחרון) לפני היציאה לאוויר הוא בקלות 6-8 שבועות או יותר עקב:
   • איסוף ראיות ידני כדי לעבור סקירות אבטחה ותאימות מעבר ל-SAST/SCA/DAST סטנדרטיים (כגון תצורת אבטחה, בקרות יום 2, תיוג ועוד).
   • איסוף ראיות ידני עבור סקירות תפעול וחוסן (כגון תמיכה בפעולות ענן והמשכיות עסקית).
   • סקירות מעבר שירות לתמיכה בשירותי IT וניהול ופתרון אירועים.

נתיב לפריסה: מצב יעד

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

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

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

מרכיבי המפתח של מודל ה-SDLC מקורי הענן כוללים:

• ארכיטקטורה ועיצוב מונעי דפוס ממוסדים ברחבי הארגון.
• דפוסים המשלבים דרישות מפתח של אבטחה, תאימות, גמישות ומדיניות ארגונית אחרת (כקוד).
• סקירות אבטחה ותאימות המואצות כדפוסים ומשמשות לתיאור הפתרון.
• פיתוח ליבה, כולל יצירת סביבות, צינורות ותצורת שירותים (שמונעת באמצעות קטלוג ארגוני של הנדסת פלטפורמות).
• צינור CI/CD/CT הבונה קישורים לכל הפעילויות על פני המסלול לפריסת מחזור החיים.
• הנדסת פלטפורמה בונה-מגדירה-מנהלת פלטפורמות ושירותים עם כל מדיניות הארגון (כגון הצפנה) מוטבעת כמדיניות פלטפורמה.
• כלי אבטחה ותאימות (לדוגמה, סריקות פגיעות או בדיקות מדיניות) ואוטומציה המשולבת בצינורות או זמינה כשירות עצמי.
• יצירת רמה גבוהה של נתונים (מיומנים, פלטי כלים ותובנות סריקת קוד) למספר סקירות ללא התערבות ידנית.
• יכולת מעקב מצבר ועד לפריסה הערות שחרור והשפעה של שינוי.
• התערבויות רק על ידי חריגים.

הנתיב לפריסה מניע האצה באמצעות בהירות, אחריות ועקיבות

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

קרא את חלק 2: חקר מודל הבשלות וגישות המימוש