Coroid מדמה מחזור חיים מלא של תוכנה, ולא רק את שלב הבנייה. רוב התהליך מתבצע אוטומטית; חלק אחד הוא נקודת בדיקה אופציונלית שניתן להפעיל כאשר העבודה חשובה מספיק כדי להצדיק זאת.
מחזור העבודה של SDLC האופציונלי
בתוך ה עבודה חדשה טופס, תחת הגדרות מתקדמות, קיים תיבה לסימון:
להשתמש במחזור העבודה של SDLC (אופציונלי) — לבחון את הכוונה והמפרטים לפני תחילת התכנון. ניתן להשאיר אפשרות זו כבויה כדי להתחיל בתכנון ישירות מהתיאור הקצר.
האפשרות זו כבויה כברירת מחדל. כאשר האפשרות כבויה, התכנון מתחיל מהתיאור הקצר לאחר שהוא עובר בדיקה. אישור כשירותכאשר האפשרות מופעלת, שני פריטים נוצרים וזקוקים לאישור ראשון:
- כוונה — המטרה האמיתית של העבודה, יחד עם ההחלטות וההנחות שעומדות בבסיסה.
- מפרטים — היקף העבודה, הסעיפים שאינם כלולים וקריטריוני הקבלה.
רק לאחר ששני אלו יקבלו אישור, יתחיל התכנון.
מתי להפעיל אותה?
הפעילו אותה כאשר עלות בניית המוצר הלא נכון גבוהה, כאשר הבקשה הגיעה מאדם שאינו מתכוון לבחון את התכנון בעצמו, או כאשר התיאור הקצר מכיל הנחה שהייתם מעדיפים לראות כתובה ומאושרת.
השאירו אותה כבויה כאשר התיאור הקצר ברור למדי. שער אישור נוסף על עבודה שגרתית יוצר חיכוך ללא תועלת — וה אישור התכנון שלב עדיין חל על כל מקרה.
חמש תחנות התהליך
מחזור החיים המלא מתבצע בחמישה שלבים, כאשר כל שלב מייצר ראיות שהשלב הבא משתמש בהן.
| תחנה | מה קורה בשלב זה? | מצב |
|---|---|---|
| הגדרה | בקשה עמומה הופכת לכוונה מאושרת, החלטות, הנחות ומדדי הצלחה. | גרסה בטא |
| ויזואליזציה | רעיונות UI אופציונליים, המעובדים ומאושרים כהנחיות עיצוב. | גרסה בטא |
| אספקה | התכנון מפורק לחלקים וסוכנים מבצעים אותו. | זמין |
| להוכיח | דרישות מתויגות למשימות, בדיקות, ממצאי ביקורת ושינויים בקובץ בקשת משיכה. | זמין |
| לשפר | מעקבים, תיקונים והערכות הופכים נסיגות לעבודה של המחזור הבא. | זמין |
- הגדרהכוונה מאושרת, החלטות, הנחות ומדדי הצלחה.בטא
- המחשהרעיונות עיצוב אופציונליים, המאושרים כהנחיות עיצוב.בטא
- אספקההתוכנית מפורקת לחלקים והסוכנים מבצעים אותה.זמין
- הוכחהדרישות מתקשרות למשימות, בדיקות, ממצאים ושינויים.זמין
- שיפורתקלות נהפכות לעבודה של המחזור הבא.זמין
אופציונליהפעילו את תהליך ה-SDLC כדי לאשר את הכוונה והמפרט לפני תחילת התכנון.
תהליך השיפור מזין את המחזור הבא: ניטור, תיקון והערכות הופכים תקלות לעבודה חדשה.
הגדרה ותצוגה הן שתי הפונקציות הנמצאות כרגע בפיתוח פעיל. אספקה, הוכחה ושיפור הן הפונקציות הפועלות על כל משימה כיום, בין אם האישור האופציונלי מופעל ובין אם לאו.
מדוע הפריטים מנוהלים לפי גרסאות
אישורים קשורים לגרסה מדויקת של פריט. עריכת פריט שכבר אושר יוצרת טיוטה חדשה במקום לשנות בשקט את מה שהוסכם עליו.
זה מה שהופך אישור לבעל משמעות. אישור שנשאר צף – קשור ל'מפרט' ולא לגרסה ספציפית שלו – מאשר כל דבר שהמסמך יאמר בהמשך, מה שבכלל אינו אישור.
תפקידי אישור
ניתן להקצות באופן עצמאי אחריות בתחומי המוצר, עיצוב, טכניקה, אבטחה ושחרור, כך שהאדם המאשר את ההשלכות בתחום האבטחה אינו בהכרח זה המאשר את היקף העבודה.
שרשרת ראיות
המטרה ביצירת ראיות בכל שלב היא שניתן יהיה לעקוב אחורה אחר תוצר pull request המוגמר: שינוי זה מממש משימה זו, שמקורה בדרישה זו, שמקורה בכוונה שאושרה.
שרשרת זו היא מה שהופך את האספקה האוטונומית לניתנת לביקורת. ללא שרשרת כזו יש לנו קוד שפועל אך ללא הסבר מדוע הוא הקוד שביקשנו.
מהקוד שנבדק לגרסה
pull request הוא תוצאת מחזור העבודה. לאחר שכללי המאגר שלך מאפשרים מיזוג, גרסה מסמנת SHA של קובץ התחייבות מלא ורושמת אילו שינויים הקובץ מכיל. שער הזמינות שלה בודק את אותו קובץ התחייבות בדיוק עבור סביבה נבחרת. אישורים קשורים לרישום של השער; עריכת המועמד או המדיניות גורמת להחלטות הקודמות להפוך ללא תוקף.
בקשת פריסה מפעילה ניסיון בצינור החיבור שלך. קריאה חוזרת מהספק או אישור ידני רושמים מה הגיע לסביבה, ורישום הקנריה שלאחר הפריסה רושם את המצב הבריאותי בנפרד. לכן, המשימה, pull request וגרסה שומרים על משמעויות נפרדות: עבודה שהושלמה אינה ראיה לכך שהקוד הגיע לסביבת ייצור.
כיצד זה קשור לתוכניות
תהליך ה-SDLC ו תוכניות הם נקודות ביקורת שונות:
- ה תהליך ה-SDLC מאשר מה צריך לבנות, עוד לפני שקיים גישה כלשהי.
- ה תוכנית מאשרת כיצד ייבנה, עוד לפני שקיים קוד.
ניתן להשתמש באחד מהם, בשניהם או באף אחד מהם. שניהם זולים יותר מאשר לבחון pull request מוגמר שאינך מסכים איתו.