ביקורת ואוטומציה

סביבות קבועות וביקורת CI

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

מנהלי לקוחותמפעילי פלטפורמה

עודכן לאחרונה 18 ביוני 2026

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

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

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

לפני שתתחילו

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

יצירת סביבה קבועה

פתחו את Environments ובחרו Create environment. Console פותח אשף בן ארבעה שלבים עם סרגל שלבים בראש: Source, Runtime, Policy ו-Review. פאנל השקה חי מצד ימין מציג את הבחירות הנוכחיות ומפרט פריטים נדרשים שעדיין חוסמים.

1. Source. בחרו את היקף הלקוח, תנו שם לסביבה, ואשרו את כתובת ה-URL של המאגר ואת ענף המקור. Console מאמת כאן את גישת הספק. כאשר שינוי תלוי ביותר ממאגר אחד, הפעילו את ערימת המאגרים כך שמאגר זמן ריצה ומאגר מוצר ייבדקו בסדר.
2. Runtime. בחרו את פרופיל הסביבה הקבועה, משפחת התבניות, יעד סביבת העבודה וגודל זמן הריצה. הפרופיל קובע את הנחות גרסת WebCentral, כולל Java, Gradle, Tomcat וחבילת הרישיון הצפויות עבור סביבת העבודה התומכת.
3. Policy. הגדירו את מקור הזרע (גיבוי מסד נתונים), החשיפה ומנוע מיגרציית מסד הנתונים. בחרו את מנוע המיגרציה התואם ליעד: Flyway, ARCHIBUS DUW או מיגרציות מושבתות.
4. Review. אשרו את תוכנית ההשקה. רשת הביקורת מסכמת את הפרופיל, מצב המאגר, הגודל וגיבוי מסד הנתונים. כאשר כל הנדרש קיים, בחרו Create environment.

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

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

השתמשו בפרופיל גרסת WebCentral התואם למאגר המקור או ל-WAR, במיוחד עבור גרסאות WebCentral ישנות יותר הזקוקות ל-Tomcat 8.5 או Tomcat 9 במקום ברירת המחדל הנוכחית. ראו הגדרות מוקדמות של סביבת עבודה כיצד פרופילים אלה ממופים להגדרות זמן ריצה.

פתיחת קיצורי דרך של זמן ריצת סביבה

לאחר שסביבת העבודה הקבועה קיימת, השתמשו בפעולות כרטיס הסביבה:

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

עדכון זמן ריצת סביבה בשני שלבים

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

1. Request environment update. זה מאשר את העדכון לסביבת העבודה הקבועה ומסמן אותו כמבוקש. Console מראה שהעדכון מוכן להתחיל אך עדיין לא נגע בסביבה הפועלת.
2. Start environment update. זה מתחיל את עדכון סביבת העבודה הקבועה וממתין לתוצאת זמן הריצה. Console מעביר את המצב לפועל, ולאחר מכן ליושם ברגע שזמן הריצה הקבוע נמצא בגרסה המקודמת.

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

יצירת פרופיל סביבת עבודה של CI

פתחו את CI & Review ובחרו Create CI profile (זה Create CI/profile בסרגל הפעולות העליון). Console פותח אשף בן ארבעה שלבים עם אותה צורת סרגל שלבים: Source, Runtime, Policy ו-Review, המוצגים באזור העבודה כ-Source route, Workspace runtime, Run policy ו-Review and create.

1. Source route. בחרו את הלקוח, הספק, המאגר, הענף וסביבת יעד אופציונלית. בחירת סביבת יעד היא מה שמפעיל את בדיקת היעד מאוחר יותר. החילו פרופיל ערימת מאגרים כאשר השינוי זקוק למאגר זמן ריצה בתוספת מאגר מוצר או תלות.
2. Workspace runtime. בחרו את צורת סביבת העבודה: review, QA, review plus QA או destination QA. בחרו את תבנית ה-CI, יעד סביבת העבודה והגודל.
3. Run policy. הגדירו שמירה, פריטים, אילו שלבים פועלים, היקף QA ומנוע מיגרציית מסד נתונים. בחרו את פרופיל גרסת WebCentral ואת גיבוי מסד הנתונים. ביקורת משתמשת בדרך כלל בהיגיון גבוה; QA משתמש בדרך כלל בהיגיון נמוך לאחר שבדיקות דטרמיניסטיות אספו ראיות.
4. Review and create. אשרו את פרופיל הנתיב ברשת הביקורת, ולאחר מכן בחרו Create CI profile.

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

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

חמש כרטיסיות CI & Review

אזור העבודה של CI & Review מאורגן בחמש כרטיסיות מעל הפאנל הראשי, לכל אחת ספירה חיה:

מעל הכרטיסיות, רצועת זרימת עבודה מציגה את צינור השלבים עבור אירוע המיזוג הנבחר: Intake, Review, QA, Target QA ו-Merge. כל שלב מציג את המצב שלו, כגון open, waiting, skipped או waiting on checks.

ענף מקור בלבד לעומת סביבת יעד

נתיבי ענף מקור בלבד מריצים ביקורת קוד ו-QA של runner ללא סביבה קבועה נבחרת. במצב זה, Console מדלג בכוונה על בדיקת סביבת היעד, ושלב Target QA מוצג כ-skipped.

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

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

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

הגדרת העברת הספק

פתחו את הכרטיסייה Provider handoff וטענו נתיב כדי לרשום או לבדוק את חיבור הספק המנוהל. Console מחזיק בשכבת הביקורת; חיבור הספק מאפשר לו לפרסם תגובות ביקורת ו-QA, לשלוח משוב מצב ולקבל אירועי מיזוג.

מכרטיסייה זו תוכלו:

• לשמור חיבור מנוהל. רשמו את אפליקציית הספק, ה-service hook או הפניית אישור מאושרת כגון token://..., k8s://secret/key או הפניית OpenBao/Vault. Console יכול גם לקבל אסימון ספק חד-פעמי או סיסמת אפליקציה ולאחסן אותם באחסון אסימוני Console, ב-Kubernetes Secret או ב-OpenBao/Vault. לאחר השמירה, Console מציג רק תצוגה מקדימה של האישור.
• לסובב את האישור. השתמשו ב-Rotate credential כאשר אסימון פג או מוחלף. הריצו בדיקת חיבור לאחר מכן.
• לבטל את האישור. השתמשו ב-Revoke credential כדי לשמור על רשומת החיבור אך להפסיק לפרסם עד שתתווסף הפניית אישור חדשה.
• להתקין או ליישב webhook. השתמשו ב-Install webhook כך שעדכוני אירועי מיזוג יגיעו ל-Console, ב-Reconcile webhook כדי לתקן hook שנסחף, וב-Remove webhook כדי לעצור אירועים. שמרו או בחרו נתיב לפני התקנת ה-webhook.
• לבדוק את החיבור. השתמשו ב-Check connection כדי לאשר תקינות לפני הסתמכות על הנתיב לביקורת, מצב או פרסום תגובות.

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

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

ביקורת אירוע מיזוג

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

1. פתחו את CI & Review.
2. בחרו את אירוע המיזוג מהכרטיסייה Merge events.
3. פתחו את Review in Console כדי לראות את ענף המקור, ענף היעד, קישור הספק, פריטי תכונה, רשימת מבקרים ושינויים מוערמים.
4. הקצו מבקרים או הוסיפו מבקר מותאם אישית, ועדכנו את הערות המבקר.
5. בחרו Start review & QA כאשר הנתיב מוכן.
6. צפו ברצועת זרימת העבודה: Intake, Review, QA, Target QA ו-Merge.

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

ביקורת Archibot ו-QA של runner יכולים לפעול בנפרד או יחד. ביקורת מתמקדת בקוד, בהקשר ה-diff המוערם, בבדיקות חסרות, בנתיבים מסוכנים ובהשפעה על תיעוד. QA מתמקד בראיות ביצוע כגון עשן דפדפן, בדיקות מסד נתונים, פקודות בדיקה נבחרות, אימות שרשרת כלים ויומני סביבת עבודה. ראו Console Bots כיצד מוגדרים בוטי הביקורת וה-QA של Archibot.

אם ריצה צריכה לעצור, השתמשו ב-Cancel run על הריצה בכרטיסייה Evidence and logs. Console מסמן את הריצה כמבוטלת.

מיזוג וקידום

Console שומר על מיזוג אנושי כברירת מחדל.

לפני ש-Merge in Console זמין:

• חייב להירשם אישור מבקר.
• שלב ביקורת הקוד המבוקש חייב לעבור.
• שלב ה-QA של runner המבוקש חייב לעבור.
• אם נבחרה סביבת יעד, בדיקת סביבת היעד חייבת לעבור.

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

יומנים, ראיות ו-Shared Drive

CI & Review ו-Environments שומרים היסטוריית אירועים ב-Console. השתמשו בציר הזמן של הריצה בכרטיסייה Evidence and logs כדי לראות שינויי שלבים, שמות עבודות, מצב סביבת יעד ושורות יומן מנוקות.

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

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

• מה השתנה, כולל כל diff מוערם?
• אילו בדיקות ביקורת, QA ויעד פעלו?
• היכן הראיות המנוקות אם הריצה זקוקה לביקורת תמיכה מאוחר יותר?

אל תשתפו:

• מפתחות API, אסימוני ספק, סודות webhook, עוגיות או קישורי הזמנה.
• Kubernetes Secrets, משתני סביבה של pod, קובצי kubeconfig או אסימוני Coder.
• כתובות URL גולמיות של מסד נתונים, תוכן גיבוי גולמי או קובצי רישיון.
• תמלילים פרטיים או היצף נתוני לקוחות.

חוסמים נפוצים

העברת תמיכה

עבור תמיכה, כללו:

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

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