Coroid מסיים בפתיחת pull request בענף נפרד משלו, מול הענף הבסיסי שלך. הוא אינו מבצע מיזוג באופן אוטומטי. המיזוג תמיד נקבע על ידי אדם, בין אם ב‑provider שלך ובין אם עם אישור ומיזוג ב‑Coroid. ראה מיזוג.
מה שמתקבל איתו
- שינוי הקוד
- בדיקות שנכתבו או עודכנו יחד איתו
- תוצאת הרצת סט הבדיקות הקיים שלך
- תוצאת שערי האיכות שהארגון שלך הגדיר
- בדיקה של ה‑diff, עם ממצאים שכבר תוקנו או שפורטו
המטרה אינה להחליף את הבדיקה שלך. המטרה היא שהבדיקה שלך לא תהיה הראשונה.
main- שינוי הקוד4 קבצים
- בדיקות שנכתבו או עודכנו2 קבצים
- סט הבדיקות הקיים שלךעברו בהצלחה
- שערי איכותמציאת ייעוץ אחת
- מעבר ביקורת2 תוקנו, 1 נרשם
מה בדיוק לבדוק
הדברים המכניים כבר נבדקו. השקיע את תשומת ליבך בדברים שרק אתה יכול לשפוט:
- האם זה פותר את הבעיה הנכונה? השווה אותו לקריטריוני הקבלה של המפרט, ולא לזיכרון של מה ביקשת.
- האם הוא מתאים למאגר הקוד? כללי קידוד, שמות, צורת ה‑abstraction. Coroid קורא את הקוד שלך כדי להסיק אותם, ובדרך כלל מנחש אותם נכון – אך לא תמיד.
- על מה הוא משפיע שאינך ציפית לו? התבונן ברשימת הקבצים לפני ה‑diff.
- האם הבדיקות החדשות משמעותיות? בדיקה שעוברת אך אינה מאשרת דבר גרועה יותר מחוסר בדיקה.
החזרת עבודה
יש לך שלוש אפשרויות, בסדר עולה מבחינת עלות:
- הוסף תגובה ובקש שינוי – המשימה חוזרת לסוכן המפתח עם הממצאים שלך, תוך שמירה על ההקשר שלה. מתאים ביותר למקרים של "זה נכון אך לא שלם".
- דחה את התוכנית ובצע ריצה מחדש – כאשר הגישה שגויה, ולא הביצוע.
- בטל את המשימה – כאשר העבודה אינה נדרשת כלל. ביטול עוצר את הריצה ומשחרר את מקום הסוכן.
היו ספציפיים בהערות התיקון כפי שהייתם עושים מול עמית. "זה לא מטפל במקרה של ערך ריק ב- parseRange"מפיק תיקון; "דורש שיפור" מפיק השערה.
איחוד
Coroid לעולם לא מבצע איחוד באופן אוטומטי. אין הגדרה שגורמת לו לאחד קבצים כשמשימה מסתיימת. איחוד מתרחש בשתי דרכים, ובכל אחת מהן אדם מחליט על האיחוד.
זה תקף גם לעבודה שהתחילה תחת מנדט גם כן. Coroid רושם את ההחלטה שהיה מקבל לגבי כל איחוד, כדי למדוד את שיקול הדעת שלו, אך לעולם לא פועל לפי הרישום הזה. ראו מה Coroid מחליט, ומה נשאר בידיכם.
ב-GitHub או ב-GitLab
אחדו את ה-pull request בספק השירות שלכם, תוך שימוש בהגנות הענפים, בדיקות החובה וכללי האישור הרגילים שלכם. ה-pull request הוא ענף רגיל – זו כוונה מכוונת – כך שהוא עובר את כל תהליכי הבדיקה וה-Continuous Integration שאתם כבר סומכים עליהם.
מ-Coroid, עם אפשרות אישור ואיחוד
מסכי הסקירה ב-Coroid כוללים אישור ואיחוד כפתור. הכפתור מבקש מאתכם אישור, ואז Coroid מבצע את האיחוד של ה-pull request עבורכם דרך GitHub או GitLab, תוך שימוש בחיבור למאגר הקוד של הפרויקט. זהו אותו תהליך איחוד כמו לחיצה על כפתור האיחוד בספק השירות שלכם, כך שהגנות הענפים, בדיקות החובה וכללי האישור חלים גם כאן. אם הם מונעים את האיחוד, Coroid מציג את הסיבה מצד הספק ואף קובץ לא ייאוחד.
מה קורה לפני האיחוד תלוי במה שאתם מאשרים:
- משימה. המשימה זקוקה קודם ל-pull request. אם עדיין אין לה כזה, מסך הסקירה מציע יצירת PR לפני אישור ואיחוד. כשאתם מאשרים, Coroid מעלה את ענף המשימה כך שה-pull request יכיל את ההתחייבויות המעודכנות שנבדקו, ואז מבצע את האיחוד של ה-pull request. אישור משימה דורש גישת כתיבה לפרויקט שלה.
- תוכנית. אי אפשר לאחד את המשימות ששייכות לתוכנית בנפרד. ה-pull request היחיד של התוכנית מאושר במסגרת סקירת הקידום שלה. Coroid בודק קודם אם ענף הבסיס לא השתנה מאז תחילת התוכנית (ראו כשענף הבסיס משתנה), הבדיקות האיכותיות הנדרשות עוברות, אין סתירות איחוד ב-pull request, ואף שער תהליך לא חוסם את התהליך. אז הוא מבצע את האיחוד של ה-pull request. אישור תוכנית דורש גישת כתיבה לפרויקט שלה.
- איחוד בכפייה. סקירת הקידום של התוכנית מציעה גם איחוד בכפייה. הוא מדלג על בדיקות ענף הבסיס, סתירות האיחוד ושערי התהליך של Coroid, אך לא על הבדיקות האיכותיות הנדרשות או על כללי ספק השירות שלכם. נדרשת סיבה כתובה, שנרשמת יחד עם הקידום, וכן גישת מנהל לפרויקט.
ה- עוזר צ'אט ו־ לקוחות MCP יכולים לאשר או לבצע force-merge של pull request גם כן. הם פועלים בשמך, ולכן חלים עליהם אותם בדיקות ואותן הרשאות פרויקט. העוזר תמיד יבקש את אישורך קודם. ביצוע force-merge על ידי לקוח MCP תמיד ימתין ב אישורים עבור אדם. האם אישור מלקוח MCP ימתין שם תלוי במדיניות האוטומציה שלך. אף אחד מהם אינו יכול לאחד משימה בודדת.
הכן את מה שיישלח לייצור
לאחר האיחוד, פתח את הֵ־טַבְּלָה של הפרויקט שלך גרסאות ובחר בֵּ־ גרסה חדשה. בחר את הֲקצאת הקוד המאוחדת שברצונך לשלוח; Coroid מציגה את בקשות המשיכה שהיא כוללת. לאחר מכן, דף הגרסה מנחה כל סביבה בארבעה שלבים: בדיקות, אישור, פריסה ומצב תקין. המאגר שלך וֵ־CI/CD עדיין אחראים על הפריסה. Coroid מסמן גרסה כמפורסמת רק כאשר צינור הייצור שלך מאשר זאת, או כאשר בעלים או מנהל רושמים פריסה חיצונית מאומתת.
הבא
גרסאות — הכן את הֲקצאת הקוד המאוחדת ועקוב אחריה בכל סביבה. לאן ללכת הלאה מציג את זרמי העבודה האחרים.