הגדרות גרסאות נמצאות יחד עם שאר ההגדרות של הפרויקט. פתחו את הפרויקט, בחרו ב הגדרות, ופתחו את גרסאות. ישנם שלושה מסכים, ו כל אחד מהם עונה על שאלה אחת.
- סביבות
- לאן נכנס שחרור? הוסיפו נקודות עצירה וסדרו אותן.
- כללי אישור
- מה חייב להתקיים קודם? אישורים, תפקידים, רשימת בדיקה וכללי תיקון מהיר לכל סביבה.
- צינור פריסה
- מי מבצע פריסה, וכיצד Coroid מקבל משוב? הפייפליין שלכם או Coroid מפעילים אותו; אסימון דיווח מאפשר ל-CI/CD לאשר את התוצאה.
רק בעלים ומנהלים יכולים לשנות את הגדרות הגרסאות. כל השאר יכולים רק לקרוא tאותן. חברו קודם כל מאגר קוד, מכיוון שכל גרסה מצביעה על קומיט בתוכו.
סביבות
לאן נכנסת הגרסה, ובאיזה סדר?
כל פרויקט מתחיל בסביבת Production. הוסיפו את תחנות הפריסה האחרות,
כמו Staging או QA, באמצעות יצירה של סביבה חדשה. תנו לכל אחת מהן שם. Coroid
מציע מפתח מהשם, למשל staging. ה-CI/CD שלכם משתמש במפתח הזה
כשהוא מדווח על פריסה, לכן שמרו על יציבותו לאחר שהפייפליינים מתחילים להשתמש בו.
קבעו את הסדר באמצעות מגיע אחרי. Staging שמגיע אחרי שום דבר ו Production שמגיע אחרי Staging יוצרים את מסלול הפריסה Staging › Production. דף הגרסה מציג את מסלול הפריסה הזה בסדר זה, וכללי האישור יכולים לדרוש שהתחנה הקודמת תעבור בהצלחה קודם.
כללי אישור
מה חייב להתקיים לפני שגרסה תתפרסם כאן?
בחרו את הסביבה בחלק העליון. הכללים משתנים לפי סביבה, כך ש-Staging elא צריך להיות קפדני כמו Production.
- אישורים נדרשים: כמה אנשים שונים חייבים לאשר. אפס מאפשר לגרסה להתפרסם מיד לאחר שהבדיקות שלה יעברו בהצלחה.
- מי יכול לאשר: תפקידי הארגון המורשים לאשר.
- הפרדת מבקש האישור ממאשרי האישור: האדם שמתחיל את הפריסה אינו יכול לאשר אותה, ומי שעורך את פרטי הגרסה אינו יכול לאשר אותם.
- בדיקות איכות עוברות בהצלחה: תמיד פעיל. תרשים האיכות של הפרויקט עם
release_validationהמפעיל מופעל נגד אותו קומיט בדיוק. פרסמו את התרשים הזה מהגדרות האיכות של הפרויקט. - הסביבה הקודמת קודםהגרסה חייבת כבר להיות מפורסמת לסביבה שאחריה מגיעה זו.
- הערות שחרור מאושרות: ההערות הנוכחיות זקוקות לאישור, וכל עריכה נוספת דורשת הערות חדשות.
- רשימת בדיקה: צעדים ידניים שמישהו מאשר בדף השחרור, כגון "בדיקת ניוד מסד נתונים". ניתן לסמן פריט כנדרש או אופציונלי. פריט נדרש יכול לאפשר חריגה זמנית. בעלים או מנהל רושמים את הסיבה ואת תאריך התפוגה – עד 24 שעות – והחריגה תקפה רק לאותו קומיט וסביבה.
- כללי תיקון מהיר: כללים מקלים יותר לתיקונים דחופים: מספר האישורים וכן האם האישור של הסביבה הקודמת והערות עדיין תקפים. בדיקות איכות ופריטי רשימת הבדיקה נדרשים תמיד, ורק בעלים ומנהלים יכולים לאשר תיקונים מהירים.
בחר פרסם כללים כדי לשמור. פרסום יוצר גרסה חדשה של הכללים. האישורים שניתנו תחת הגרסה הישנה יהיו מיושנים, ולכן שחרור בתהליך יבקש אישור מחדש. סביבה ללא כללים מפורסמים לא תוכל לעבור את הבדיקות, והמסך יציג זאת.
נתיב פריסה
מי מפעיל את הפריסה, וכיצד Coroid לומד מה קרה?
בחר את הסביבה בראש הדף, ולאחר מכן קבע כיצד תתבצע הפריסה:
- הנתיב שלי מפריס באופן אוטומטי: שמור על התהליך הנוכחי שלך. Coroid רושם את הפריסות כאשר CI/CD מדווח עליהן, או כאשר בעלים או מנהל רושמים פריסה חיצונית בדף השחרור.
- Coroid מפעיל תהליך עבודה של GitHub Actions או Coroid מפעיל נתיב פריסה של GitLab CI/CD: זמין כאשר מאגר הקוד של הפרויקט נמצא אצל אותו ספק. הזן את הענף או התג שמצביע על קומיט השחרור, קובץ תהליך העבודה עבור GitHub, ואת שם המשימה המבצעת את הפריסה. Coroid בודק את ה-ref לפני תחילת הריצה ובודק את המשימה המצוינת לפני שמקבל הצלחה.
תחת דוחות פריסה, צור טוקן דיווח עבור הסביבה ושמור אותו כסוד ב-CI/CD. Coroid מציג את הטוקן פעם אחת ושומר רק את ההאש שלו. החלפת הטוקן מבטלת מיד את הקודם. אותו מסך מציג את כתובת ה-Endpoint, מזהה הפרויקט ומפתח הסביבה שהנתיב שלך זקוק להם, וכן האם הדוחות מגיעים. אירועי פריסה והגדרת CI מכיל את פורמט האירוע ודוגמאות.
העברת הגדרות בין ארגונים
ייצוא והיבוא של הגדרות כוללים את הסביבות, סדרן, תצורת הנתיב, וכללים מפורסמים, כולל כללי תיקון מהיר. טוקני דיווח לעולם לא יוצאו. יש ליצור חדשים לאחר ייבוא.