انتقال جریان کاری تحویل نرم‌افزار به GitHub با استفاده از Agent Apps

در دنیای توسعه نرم‌افزار مدرن، توسعه‌دهندگان با مانعی بزرگ به نام «تعویض زمینه» یا Context Switching روبرو هستند؛ وضعیتی که در آن برای تکمیل تنها یک چرخه کاری، مجبورند میان اپلیکیشن‌ها و تب‌های مختلف جابه‌جا شوند [S3]. این پراکندگی، بهره‌وری را به شدت کاهش می‌دهد. برای مقابله با این چالش، GitHub قابلیت جدیدی به نام agent apps را معرفی کرده است. این اپلیکیشن‌ها، ادغام‌های شخص‌ثالث (third-party) هستند که ابزارهای ضروری را مستقیماً از طریق تب "Agents" یا از طریق کامنت‌های Pull Request (PR)، به رابط کاربری GitHub می‌آورند [S1]. هدف نهایی GitHub این است که با تجمیع ابزارهای مربوط به تعیین محدوده (scoping)، امنیت (securing)، عرضه (rolling out) و تحویل (shipping) ویژگی‌ها، یک «پنل واحد» (single pane of glass) برای کل چرخه حیات توسعه نرم‌افزار (SDLC) فراهم کند [S3].

چالش اصلی: هزینه سنگین تعویض زمینه (Context Switching)

تجربه فعلی توسعه‌دهندگان اغلب مستلزم جابه‌جایی مداوم بین پلتفرم‌های ناهمگون است؛ از ابزارهای تحلیل داده (analytics) گرفته تا اسکنرهای وابستگی (dependency scanners)، سرویس‌های مدیریت ویژگی (feature flagging) و سیستم‌های مدیریت حوادث (incident management) [S3]. این تکه‌تکه بودن ابزارها منجر به از دست رفتن قابل توجه بهره‌وری می‌شود. داده‌ها نشان می‌دهند که اگرچه ابزارهای توسعه‌دهنده ضروری هستند، اما اغلب با امتیاز پذیرش بسیار پایینی روبرو هستند؛ به‌طوری که امتیاز عمومی ابزارهای توسعه‌دهنده تنها ۲ از ۱۰۰ است که این موضوع نشان‌دهنده نیاز مبرم به راهکارهای یکپارچه‌تر و کاربرپسندتر است [S3].

راهکار: اپلیکیشن‌های عامل (GitHub Agent Apps)

اپلیکیشن‌های عامل GitHub به توسعه‌دهندگان این امکان را می‌دهند که بدون ترک محیط اصلی کدنویسی خود، با سرویس‌های شخص‌ثالث تعامل داشته باشند [S1]. این اپلیکیشن‌ها از همان پلتفرم و زیرساخت (harness) مورد استفاده در Copilot cloud agent قدرت می‌گیرند [S1].

روش‌های تعامل و عملکرد اصلی

توسعه‌دهندگان می‌توانند از طریق دو روش اصلی با این عامل‌ها (agents) درگیر شوند: ۱. تب Agents: یک رابط کاربری اختصاصی در داخل GitHub برای مدیریت و دسترسی به قابلیت‌های عامل‌ها [S1, S3]. ۲. کامنت‌های Pull Request: توسعه‌دهندگان می‌توانند با اشاره مستقیم (mention) به یک عامل در رشته‌ی کامنت‌های یک PR، اقدامات خاصی را فعال کنند [S1, S3].

شرکای نخستین و دسترسی‌پذیری

مجموعه اولیه از agent apps از طریق GitHub Marketplace در دسترس هستند [S1, S3]. برخی از شرکای کلیدی و نخستین این مجموعه عبارتند از:

• Amplitude [S1, S3]
• Endor Labs [S1, S3]
• LaunchDarkly [S1, S3]
• PagerDuty [S1, S3]
• Packfiles [S1]
• Miro [S1]
• Bright Security [S1]
• SonarQube [S1]
• Octopus Deploy [S1]

ساده‌سازی SDLC: یک جریان کاری چهار مرحله‌ای

ادغام این اپلیکیشن‌ها اجازه می‌دهد تا انتقال میان مراحل مختلف تحویل نرم‌افزار، یعنی تعیین محدوده، تامین امنیت، عرضه و تحویل، به شکلی بی‌وقفه انجام شود [S2].

۱. تعیین محدوده (Scoping): پرس‌وجو از بینش‌های محصول با Amplitude

حتی پیش از آنکه کدی نوشته شود، توسعه‌دهندگان می‌توانند از اپلیکیشن عامل Amplitude برای اتخاذ تصمیمات مبتنی بر داده استفاده کنند [S3]. به‌جای باز کردن یک پلتفرم تحلیل داده مجزا، یک توسعه‌دهنده می‌تواند مستقیماً در داخل GitHub از بینش‌های محصول (product insights) پرس‌وجو کند [S3].

• مثال کاربردی: یک تیم محصول ممکن است بخواهد بداند آیا اختیاری کردن مرحله «دعوت از هم‌تیمی» در فرآیند ورود کاربر (onboarding)، با نرخ حفظ کاربر (retention) یا موفقیت در قیف فروش (funnel success) همبستگی دارد یا خیر [S3]. این عامل به توسعه‌دهنده اجازه می‌دهد تا این حدس‌ها را مستقیماً در رابط کاربری GitHub تأیید کند [S3].

۲. تامین امنیت (Securing): مدیریت پیش‌دستانه وابستگی‌ها با Endor Labs

با پیشرفت توسعه به مرحله ساخت (build)، امنیت به یک اولویت تبدیل می‌شود. اپلیکیشن عامل Endor Labs با تبدیل بررسی وابستگی‌ها به بخشی پیش‌دستانه از فرآیند بررسی کد (code review)، امکان «انتقال امنیت به سمت چپ» (shifting security left) را فراهم می‌کند [S1, S3].

• مکانیزم عملکرد: هنگامی که توسعه‌دهنده‌ای یک PR باز می‌کند که وابستگی‌ها (dependencies) را به‌روز می‌کند، می‌توان عامل را در کامنتِ PR صدا زد تا وابستگی‌های تغییر یافته را شناسایی کرده و آن‌ها را از نظر آسیب‌پذیری‌های شناخته‌شده یا ریسک‌های گسترده‌تر بسته‌ها بررسی کند [S1].
• مزیت: این کار بازخورد فوری را در داخل رشته‌ی PR فراهم می‌کند و جایگزین مدل سنتی و واکنشی (reactive) می‌شود که در آن توسعه‌دهنده منتظر می‌ماند تا اسکن CI با شکست مواجه شود و سپس اقدام به رفع مشکل کند [S1].

۳. عرضه (Rolling Out): مدیریت خودکار ویژگی‌ها با LaunchDarkly

برای کاهش اصطکاک در هنگام عرضه ویژگی‌های جدید، اپلیکیشن عامل LaunchDarkly تنظیم خودکار پرچم‌های ویژگی (feature flags) را مستقیماً از طریق یک Pull Request انجام می‌دهد [S3].

• مکانیزم عملکرد: یک توسعه‌دهنده می‌تواند عامل را در کامنتِ PR با ذکر پارامترهای خاصِ پرچم (flag) صدا بزند، پارامترهایی نظیر:
  • Key [S1]
  • Type [S1]
  • Default [S1]
  • Target [S1]
  • درصد عرضه (Rollout percentages) [S1]
• خودکارسازی: این عامل می‌تواند پرچم را در LaunchDarkly ایجاد کرده و به‌طور خودکار پیاده‌سازی کد را برای بررسی (review) ثبت (commit) کند [S1].
• حاکمیت (Governance): برای حفظ نظارت انسانی، اگر یک محیط هدف نیاز به تأیید داشته باشد، عامل به‌جای اعمال مستقیم تغییراتِ هدف‌گذاری، یک درخواست تأیید (approval request) ایجاد خواهد کرد [S1].

۴. تحویل (Shipping): ارزیابی ریسک استقرار با PagerDuty

پیش از آنکه یک ویژگی ادغام (merge) و مستقر (deploy) شود، اپلیکیشن عامل PagerDuty به ارزیابی سلامت عملیاتی سرویس کمک می‌کند تا از شکست‌های پرریسک در هنگام استقرار جلوگیری شود [S3].

• مکانیزم عملکرد: این عامل، حوادث (incidents) فعال یا حوادثی که اخیراً رخ داده‌اند را در رابطه با آن سرویس بررسی می‌کند [S3].
• ارزیابی ریسک: با نگاشت (mapping) تغییراتِ PR به بخش‌هایی که در حوادث قبلی نقش داشته‌اند، این عامل می‌تواند توصیه کند که آیا تیم باید استقرار را ادامه دهد یا خیر [S3]. این فرآیند، یک بررسی موردی و پراکنده را به بخشی روتین از فرآیند پیش از ادغام (pre-merge) تبدیل می‌کند [S3].

تمایز فنی: Agent Apps در مقابل Agentic Workflows

برای ذینفعان فنی، تشخیص تفاوت میان GitHub Agent Apps و GitHub Agentic Workflows (که در حال حاضر در مرحله پیش‌نمایش فنی است) بسیار مهم است [S4].

GitHub Agentic Workflows برای مدیریت وظایف تکراری در سطح مخزن طراحی شده‌اند، از جمله:

• دسته‌بندی مستمر (Continuous Triage): خلاصه‌سازی، برچسب‌گذاری و مسیریابی Issueهای جدید [S4].
• مستندسازی مستمر (Continuous Documentation): همسو نگه داشتن فایل‌های README با تغییرات کد [S4].
• بهداشت کیفیت مستمر (Continuous Quality Hygiene): بررسی پیش‌دستانه شکست‌های CI و پیشنهاد اصلاحات [S4].
• ساده‌سازی مستمر کد (Continuous Code Simplification): شناسایی بهبودهای احتمالی و باز کردن PR برای آن‌ها [S4].

نتیجه‌گیری

معرفی اپلیکیشن‌های عامل، نشان‌دهنده تلاش قابل توجه GitHub برای تبدیل شدن به مرکز اصلی تمامی فعالیت‌های توسعه‌دهندگان است [S3]. GitHub با ادغام ابزارهای تخصصی شخص‌ثالث در جریان کاری موجود، قصد دارد تعویض زمینه را کاهش دهد، همکاری در طول چرخه SDLC را تقویت کند و در نهایت منجر به تحویل نرم‌افزار سریع‌تر، ایمن‌تر و قابل‌اعتمادتر شود [S2, S3].