GitHub در Code Quality امکان رفع گروهی ایرادها با Copilot را اضافه کرده است. کاربر میتواند در یک صفحه تا ۲۵ مورد استاندارد را انتخاب کند و همه را در یک نوبت به Copilot بسپارد. عامل روی شاخهای جداگانه تغییرات را انجام میدهد، نتیجه را بررسی میکند و در پایان یک درخواست ادغام برای بازبینی انسان میسازد.
اهمیت این تغییر فقط در سریعتر شدن تولید اصلاح نیست. بخشی از بدهی فنی حالا میتواند بهصورت یک بسته کاری به عامل واگذار شود. در نتیجه، نقطه اصلی کنترل از «تولید پیشنهاد» به «آزمون، بازبینی و تأیید مجموعهای از تغییرات ساختهشده توسط عامل» منتقل میشود.
یک انتخاب میتواند به مأموریتی چندموردی تبدیل شود
GitHub میگوید گزینه Assign to Copilot جای مسیر قبلی Generate fix برای اصلاح تکموردی را میگیرد. از یک تا ۲۵ یافته Code Quality را میتوان با هم انتخاب کرد و به عامل ابری Copilot سپرد. مستندات Code Quality نیز توضیح میدهد که این سامانه روی شاخه اصلی مشکلات نگهداشتپذیری و قابلیت اطمینان را پیدا میکند و میتواند اصلاح آنها را به Copilot واگذار کند.
واحد کار در نتیجه عوض میشود. بهجای اینکه هر ایراد یک پیشنهاد جدا بسازد، عامل ممکن است چند ایراد را با هم تفسیر کند، چند فایل را تغییر دهد، آزمون اجرا کند و یک درخواست ادغام واحد تحویل دهد. برای تیمی با بدهی فنی زیاد، این یعنی فهرست یافتهها میتواند به صفی از کارهای اجرایی تبدیل شود.
سیاست قبلی برقرار است، اما پذیرش باید مستقل بماند
GitHub اعلام کرده اصلاح گروهی از همان سیاست سازمانی Code Quality پیروی میکند و تنظیم جداگانهای برای آن وجود ندارد. هر بار سپردن کار به Copilot نیز AI Credits مصرف میکند.
این سادگی مدیریتی مفید است، اما اجازه استفاده از Code Quality لزوماً همان تصمیمی نیست که اجازه ایجاد حجم زیادی تغییر در کد را میدهد. بررسیای که خود عامل روی خروجیاش انجام میدهد نیز نباید جای پذیرش مستقل را بگیرد.
مرز مناسب همچنان درخواست ادغام است. حفاظت شاخه، آزمونهای اجباری، قوانین مالکیت کد و تأیید انسانی میتوانند بیرون از چرخه عامل باقی بمانند، حتی اگر ساخت شاخه و تولید اصلاح به Copilot سپرده شده باشد.
بسته بزرگتر میتواند خطاهای مرتبط ایجاد کند
یک اصلاح خودکار بد معمولاً اثر محدودی دارد. اما در یک بسته چندموردی، یک برداشت اشتباه مشترک ممکن است همزمان چند بخش را تغییر دهد؛ بهویژه وقتی ایرادها به یک کتابخانه مشترک، پیکربندی یا آزمونها مربوط باشند.
تحلیل Aipolix این است که تیم باید کل بسته را بهعنوان یک کار واگذارشده ببیند، نه ۲۵ موفقیت مستقل. سابقه بازبینی باید نشان دهد هر یافته به کدام تغییر منجر شده، چه فایلهایی دست خورده، چه آزمونهایی اجرا شده و آیا اصلاح یک مورد بر فرضهای مورد دیگر اثر گذاشته است.
افزایش سرعت اجرای خودکار میتواند شعاع اثر یک فرض اشتباه را هم بیشتر کند. اگر یک درخواست ادغام بزرگ ارتباط میان یافته و تغییر را پنهان کند، تشخیص این خطا سختتر میشود.
مصرف اعتبار، پاکسازی بدهی فنی را به تصمیم تخصیص منابع تبدیل میکند
از آنجا که سپردن کار به Copilot اعتبار هوش مصنوعی مصرف میکند، پاکسازی Code Quality با استفادههای دیگر عامل مانند توسعه قابلیت، امنیت و بازبینی برای یک منبع مشترک رقابت میکند.
وجود هزاران یافته نباید بهطور خودکار به هزاران مأموریت عامل تبدیل شود. تیم میتواند ابتدا بر پایه خطر و هزینه بازبینی اولویتبندی کند و سپس تعداد اصلاحات پذیرفتهشده به ازای اعتبار مصرفشده و زمان بازبین را بسنجد. اگر خروجی عامل نیازمند بازکاری زیاد باشد، تعداد مأموریتهای انجامشده معیار خوبی برای ارزش واقعی نیست.
دسترسی گسترده است، اما شرط دارد
این قابلیت برای مخزنهایی ارائه شده که GitHub Code Quality روی آنها فعال است و در GitHub Team یا GitHub Enterprise Cloud قرار دارند؛ محیطهای دارای محل نگهداری داده نیز در این دامنه هستند. عامل ابری Copilot هم باید برای مخزن قابل استفاده باشد.
این محدوده اجرای مرحلهای را ممکن میکند. سازمان میتواند ابتدا چند مخزن را آزمایش کند و کنترلهای ادغام موجود را دستنخورده نگه دارد.
چه چیزی را باید سنجید
سؤال مناسب این نیست که Copilot آیا میتواند ۲۵ مورد را در یک فرمان پردازش کند یا نه. بهتر است تعداد ایرادهای واقعاً رفعشده، خطاهای تازه، زمان بازبینی، پوشش آزمون، تغییرات خارج از محدوده، مصرف اعتبار و تعداد بستههایی که بازبین مجبور به تقسیم یا رد آنها میشود سنجیده شود.
GitHub با این تغییر Code Quality را از پیشنهادهای جداگانه به سمت واگذاری واقعی کار میبرد. ظرفیت اجرا بیشتر میشود، اما پذیرش تغییر، اختیار ادغام و پاسخگویی درباره هزینه باید همچنان بیرون از تصمیم خود عامل بماند.