גרסאות

המפעל הופך משימות ותוכניות ל־Pull Request שנבדקו. לאחר שהם ממוזגים, Release עונה על השאלה הבאה: איזה חלק מהעבודה פועל באיזו סביבה, והאם היה בטוח להפעיל אותו שם?

גרסה מקבעת commit מדויק אחד של Git ועוקבת אחריו בסביבות שלכם, למשל Staging ואז Production. ה־commit כבר יכול להימצא בענף הפריסה שלכם, או ש־Coroid יארוז תחילה pull requests פתוחים בתוך pull request של הגרסה, ש־commit המיזוג שלו יהפוך לגרסה. בכל תחנה, Coroid בודק את ה־commit, אוסף את האישורים שביקשתם ומתעד את הפריסה שעליה CI/CD מדווח. Coroid לעולם אינו מסמן שגרסה נפרסה על סמך דבריו בלבד. צינור העבודה שלכם, או אדם שמתעד פריסה חיצונית, חייבים לאשר זאת.

הרעיון בדקה אחת#

• Release: תיקון אחד, שם, וגרסה אופציונלית. גרסה כמו 2.4.0 היא אופציונלית, כך שאספקה רציפה פועלת ללא תגים.
• סביבה: נקודת עצירה בדרך אל המשתמשים שלכם, כמו שלב הביניים או הייצור. כל פרויקט מגדיר את נקודות העצירה שלו ואת סדרן.
• פריסה: אילו סביבות הגיעה אליהן הגרסה עד כה.
• עבודה: המשימות שתוכננו לגרסה והשינויים הממוזגים שהיא מכילה, המוצגים כאחוז מהסך הכולל.
• ארבעה שלבים לכל סביבה: בדיקות, אישור, פריסה, ומצב תקין. דף הגרסה תמיד פותח את השלב שדורש את התערבותכם.
• אריזה: גרסה שנבנתה מ־pull requests פתוחים. Coroid ממזג אותם לענף גרסה אחד, בסדר שתוכלו לשנות, ופותח pull request של הגרסה אחד. לגרסת חבילה יש שלב חמישי, אריזה, לפני הבדיקות.

קראו על גרסה במבט חטוף#

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

בחרו גרסה כדי לפתוח את דף הגרסה שלה.

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

ארבעת השלבים בכל סביבה#

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

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

פריסה. כאשר הבדיקות והאישורים מושלמים, הגרסה מוכנה לסביבה. אם Coroid מחובר ל־GitHub Actions או ל־GitLab CI/CD עבור אותה סביבה, בעלים או מנהל בוחרים פרוס ל… ו־Coroid מתחיל את קו האספקה עבור אותו תיקון מדויק. במקרה אחר, קו האספקה שלכם מבצע את הפריסה בעצמו ומדווח בחזרה. בכל מקרה, השלב הופך לירוק רק כאשר מתקבל אישור על הצלחה.

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

מה משמעות המצבים?#

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

זרמי עבודה#

הגדרת שחרורים לפרויקט#

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

1. ב- סביבות, הוסיפו את תחנות העצירה שלכם וסדרו אותן – למשל סביבת staging לפני production.

2. ב- כללי אישור, פרסמו כללים לכל סביבה: כמה אישורים נדרשים, מאילו תפקידים, ואילו פריטי רשימה יש לבדוק. סביבה לא תוכל לעבור את הבדיקות שלה עד שכללי האישור יפורסמו.

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

4. ב- גרסאות, בחרו מאין תגיע גרסת השחרור, ותנו לכל סביבה כתובת URL של גרסה כדי ש-Coroid יוכל לאשר מה רץ שם.

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

שחררו עבודה מתוכננת#

השתמשו בזה כשאתם יודעים מראש מה צריך לצאת יחד.

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

אריזת pull requests פתוחים#

השתמשו בזה כשישנם מספר pull requests בתור, מצד Coroid או מהצוות שלכם, ושצריכים לצאת יחד.

1. בחרו שחרור חדש, בחרו את הפרויקט, ובחרו Pull requests פתוחים. האפשרות דורשת מאגר GitHub או GitLab, ולכן פרויקטים שמאוחסנים ב-Coroid משחררים מחויבות.
2. Coroid מציג את ה-Pull requests הפתוחים לענף הפריסה, מהבטוח ביותר קודם. pull request ש-Coroid פתח מוצג כמשימה או תוכנית שלו. Coroid שוקל את מה שספקית הפיתוח והסקירה שלו כבר יודעים: בדיקות, סקירות, גודל, סתירות, וקבצים שכמה Pull requests נוגעים בהם. הוא משמיט טיוטות, בדיקות כושלות, שינויים שנדרשו ו-Pull requests מפורקים, ומסביר מדוע.
3. בטלו את הסימון של מה שצריך לחכות, והשתמשו בחצים כדי לשנות את הסדר. Pull request שמתבסס על אחר (Pull request משולב של pull request, או כזה שכותב 'תלוי ב-#12') תמיד יבוא אחריו.
4. בחרו יצירת שחרור. Coroid יוצר release/<version> מהענף שמיועד לפריסה, ממזג את בקשות המשיכה לפי הסדר ופותח pull request של הגרסה, שמפרט את כולן ומקשר אליהן.
5. אם יש סתירה בין pull request לענף השחרור, אריזה שלב עוצר שם ומציג את הקבצים. בחרו פתרון באמצעות Coroid כדי לאפשר לסוכן המפתח לבצע את המיזוג ולפתור את הסתירה במשימה, או השאירו אותו בחוץ כדי להמשיך בלעדיו.
6. עברו על pull request של הגרסה ומזגו אותו עם מחויבות מיזוג. הספק שלכם יסמן אז כל pull request שנכלל כממוזג. Coroid יקבע את קומיט המיזוג כקומיט הגרסה, יתעד את בקשות המשיכה שנכללו כתוכן שנשלח, ויסגור כל בקשה שעדיין פתוחה עם קישור ל-pull request של הגרסה.
7. עברו על ארבעת השלבים עבור כל סביבה כרגיל.

גם מיזוגי squash או rebase עובדים, אך ה-Pull requests המקוריים לא יסומנו כממוזגים על ידי הספקית שלכם. Coroid יסגור אותם עם תגובה במקום.

שלחו את מה שנמצא בענף הראשי#

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

1. בחרו שחרור חדש ובחרו את המחויבות, בדרך כלל האחרונה בענף הפריסה.
2. תחת השוואה עם, בחרו את הסביבה שאתם עומדים להחליף. Coroid יציג את ה-Pull requests והמחויבויות שבין מה שרץ שם לבין המחויבות שלכם, ויבחר את אלו שהוא יכול לאשר.
3. השאירו את השם והגרסה ריקים אם תרצו. Coroid יקרא לשחרור על פי התאריך וקיצור המחויבות, ומקור הגרסה של הפרויקט ימלא את פרטי הגרסה. לכל שחרור יינתן גם מספר בנייה עוקב.
4. צרו את השחרור ועברו על ארבעת השלבים.

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

שלח תיקון דחוף#

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

התאושש כשמשהו נכשל#

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

מהצ'אט או מהעורך שלך#

לסייען הצ'אט ולשרת ה-MCP של Coroid יש את אותם כלים לניהול גרסאות: רשימה ובדיקה של גרסאות, בחירת קומיט, צפייה במה שיישלח לפריסה, הכנת גרסה, אריזת Pull Requests פתוחים, הפעלת הבדיקות שלהם, אישורם, בקשת פריסה וכתיבת הערות טיוטה. אריזה, אישור ופריסה תמיד דורשים אישור של אדם. ראה סייען צ'אט ו Coroid כשרת MCP.

שחרר מספר פרויקטים יחד#

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

מה Coroid עושה ומה לא עושה#

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

קשורים#

• הגדרות גרסה
• אירועי פריסה והגדרת CI
• הכנס את הגרסה לתוך הבנייה שלך
• התאוששות ורכבות גרסאות
• ספרינטים
• משימות, תוכניות, ספרינטים ונתיבים
• איכות וראיות לביקורת