שתף באמצעות

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

  • מאמר

חלה על המלצה זו של רשימת פעולות לביצוע של Power Platform Well-Architected Operational Excellence:

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

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

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

אסטרטגיות מרכזיות בתכנון

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סיוע של Power Platform

קווי הצינור ב- Power Platform שואפים לדמוקרטיזציה של ניהול מחזור חיים של אפליקציות (ALM) עבור לקוחות Dynamics 365 ו- Power Platform על-ידי הוספת אוטומציה של ALM ויכולות אינטגרציה רציפה ואספקה ​​רציפה (CI/CD) לשירות.

ניתן להשתמש בכלי יצירה של Microsoft Power Platform עבור Azure DevOps כדי להפוך לאוטומטיות משימות בנייה ופריסה נפוצות שמבוססות על Power Platform.

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

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

אוטומציה של בדיקות עם קווי צינור של Azure DevOps.

API אינטרנט של בודק Power Apps מספק מנגנון להפעלת בדיקות ניתוח כנגד התאמות אישית והרחבות בפלטפורמת Microsoft Dataverse.

Microsoft Power Platform CLI ‏(PAC CLI) הוא כלי שורת פקודה התומך, בין היתר, בייבוא ​​וייצוא של פתרונות Power Platform, ובאריזה וביטול אריזה מקובצי מקור של פתרונות Power Platform. PAC CLI זמין ככלי שורת פקודה עצמאי או כהרחבה עבור Visual Studio Code.

אפשר להשתמש ב- Terraform, ב- Bicep וב- Azure Resource Manager לפריסות תשתית בלתי ניתנת לשינוי כקוד (IaC). בהתאם לדרישות שלכם ולהיכרות הצוות עם הכלים, ייתכן שתשתמשו בכלי אחד או יותר מהכלים הללו לפריסות ולניהול המשאבים.

תיאום ארגוני

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

למידע נוסף, ראו מהו אזור נחיתה של Azure? ועקרונות התכנון של אזור הנחיתה של Azure.

למידע נוסף

רשימת בדיקה למצוינות תפעולית

עיין במכלול ההמלצות המלא.

רשימת תיוג למצוינות תפעולית