GitHub Agentic Workflows: כתבו CI/CD בשפה טבעית

נקודה מרכזית

הריפו GitHub Agentic Workflows (gh-aw) הוא פריימוורק שמאפשר לנו להגדיר אוטומציית CI/CD באמצעות מרקדאון בשפה טבעית במקום קונפיגורציית YAML מסורתית. פותח על ידי GitHub, הוא מאפשר לסוכני AI לבצע משימות מורכבות ורב-שלביות כמו טריאז' של באגים, קוד ריוויו, ותיקונים אוטומטיים - הכל רץ בצורה מאובטחת בתוך GitHub Actions עם מגבלות אבטחה מובנות.

מה זה GitHub Agentic Workflows?

הריפו GitHub Agentic Workflows (gh-aw) הוא פריימוורק שמשנה את הצורה שבה אנחנו ניגשים לאוטומציית CI/CD. הפרויקט gh-aw פותר את הבעיה של שילוב סוכני AI אינטליגנטיים בתהליכי הפיתוח שלנו בלי לוותר על אבטחה או שליטה.

במקום לכתוב קבצי קונפיגורציה של YAML נוקשים שקורסים בגלל הזחה לא נכונה אחת, אנחנו כותבים מסמכי מרקדאון בשפה טבעית שמתארים מה אנחנו רוצים שיקרה. המערכת מתזמרת סוכני AI שמבצעים את התהליכים האלה ישירות בתוך GitHub Actions - אותה תשתית מאובטחת שאנחנו כבר סומכים עליה לפייפליינים של CI/CD.

הבעיה שכולנו מכירים

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

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

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

איך GitHub Agentic Workflows עובד

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

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

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

התחלה מהירה

ככה אנחנו מתחילים עם GitHub Agentic Workflows:

# התקנת הרחבת CLI של gh-aw
gh extension install github/gh-aw

# אתחול תהליך עבודה חדש
gh aw init

# יצירת קובץ תהליך ב-.github/workflows/
# במקום YAML, אנחנו כותבים מרקדאון
cat > .github/workflows/bug-triage.md << EOF
# תהליך טריאז' של באגים

כשבעיה חדשה מתויגת כ-'bug':
1. נתח את הודעת השגיאה והסטאק טרייס
2. חפש בקוד קשור
3. זהה סיבות אפשריות
4. הוסף תגובה עם ניתוח
5. הצע חברי צוות רלוונטיים להקצאה
EOF

# הסוכן מטפל בשאר
gh aw run bug-triage

דוגמה אמיתית

נגיד שאנחנו רוצים לבצע אוטומציה לתהליך קוד ריוויו. הנה איך תהליך עבודה אמיתי נראה:

# תהליך עוזר לקוד ריוויו

## טריגר
כש-PR נפתח

## משימות

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

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

### פידבק
- פרסם תגובת ריוויו עם הממצאים
- הצע שיפורים ספציפיים עם דוגמאות קוד
- סמן בעיות חוסמות שדורשות ריוויו אנושי
- אשר שינויים פשוטים אוטומטית (עם אופציה לביטול)

## מגבלות אבטחה
- גישה לקריאה בלבד לריפו
- לא יכול למרג' או לאשר בלי אישור אנושי
- כל הפעולות נרשמות לביקורת

פיצ'רים מרכזיים

• תהליכי עבודה בשפה טבעית - אנחנו כותבים מה אנחנו רוצים שיקרה במרקדאון, לא ב-YAML. תחשבו על זה כמו לכתוב הוראות לעמית חכם במקום לתכנת מכונה. הסוכן מפרש את הכוונה שלנו ומבין את פרטי היישום.
• מגבלות אבטחה מובנות - כברירת מחדל, סוכנים רצים עם הרשאות קריאה בלבד. תחשבו על זה כמו לתת למישהו גישת תצפית לקוד שלנו - הם יכולים להסתכל ולנתח, אבל לא יכולים לעשות שינויים בלי אישור מפורש. פעולות רגישות דורשות הרשאה אנושית דרך שערי אישור.
• הרצה מבודדת - כל תהליך עבודה רץ בסביבה מבודדת בתוך GitHub Actions. הקטע המדליק הוא שזה כמו לתת לכל סוכן חדר נעול משלו לעבוד בו - הם לא יכולים לגשת או להשפיע על כלום מחוץ לאזור העבודה המיועד להם. זה מונע מסוכן בודד לפגוע בכל המערכת שלנו.
• אוטומציה של משימות רב-שלביות - סוכנים יכולים לבצע רצפים מורכבים כמו "נתח את הבאג הזה, חפש בעיות דומות, הצע תיקון, הרץ בדיקות, ותיצור PR." במקום שנכתוב סקריפטים נפרדים לכל שלב ונחבר אותם ביחד, הסוכן מתזמר את כל התהליך על בסיס התיאור הכללי שלנו.
• אינטגרציה עם GitHub Actions - תהליכים רצים על אותה תשתית שאנחנו כבר משתמשים בה ל-CI/CD. מה שנקרא - אנחנו מקבלים את אותה אמינות, רישום, ניהול סיקרטים, ובקרות אבטחה שכבר הגדרנו. אין תשתית חדשה לתחזק או ללמוד.

מתי להשתמש ב-GitHub Agentic Workflows לעומת אלטרנטיבות

כלי CI/CD מסורתיים כמו Jenkins, CircleCI, או תהליכי GitHub Actions רגילים מצוינים כשאנחנו יודעים בדיוק מה צריך לקרות ויכולים לכתוב את זה בצורה מפורשת. הם דטרמיניסטיים וצפויים - אותו קלט תמיד מייצר אותה פלט.

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

לתזמור סוכנים טהור מחוץ להקשר של CI/CD, כלים כמו LangChain או CrewAI מציעים יותר גמישות. אבל אם אנחנו רוצים את הסוכנים שלנו משולבים בתהליך הפיתוח שלנו עם מודל האבטחה של GitHub, gh-aw בנוי בדיוק בשביל זה.

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

בעיניי - האם אשתמש בזה?

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

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

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

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

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

בדקו את הפרויקט: gh-aw בגיטהאב

שאלות נפוצות

מה זה GitHub Agentic Workflows?

GitHub Agentic Workflows (gh-aw) הוא פריימוורק שמאפשר למפתחים להגדיר תהליכי אוטומציית CI/CD באמצעות מרקדאון בשפה טבעית במקום קונפיגורציית YAML, מה שמאפשר לסוכני AI לבצע משימות מורכבות ורב-שלביות בתוך GitHub Actions.

מי יצר את GitHub Agentic Workflows?

הריפו GitHub Agentic Workflows נוצר על ידי GitHub. הוא מייצג את החזון שלהם לשילוב סוכני AI בתהליכי פיתוח תוך שמירה על תקני האבטחה והאמינות שGitHub Actions ידועה בהם.

מתי כדאי להשתמש ב-GitHub Agentic Workflows?

כדאי להשתמש ב-GitHub Agentic Workflows כשאנחנו צריכים אוטומציה אינטליגנטית שיכולה להסתגל לקונטקסט ולקבל החלטות - כמו טריאז' של באגים, עזרה בקוד ריוויו, או ניתוח אוטומטי של בעיות - ולא רק פייפליינים סקריפטיים של CI/CD.

מה האלטרנטיבות ל-GitHub Agentic Workflows?

ל-CI/CD מסורתי, GitHub Actions רגיל, Jenkins, או CircleCI עובדים מצוין לתהליכים דטרמיניסטיים. לתזמור כללי של סוכנים, LangChain או CrewAI מציעים יותר גמישות אבל חסרים את האינטגרציה הנייטיבית לגיטהאב ומודל האבטחה. לאוטומציה פשוטה, תהליכי GitHub Actions עם כלים קיימים עשויים להספיק בלי צורך ביכולות של סוכנים.

מה המגבלות של GitHub Agentic Workflows?

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