قامت GitLab بأتمتة دورة Merge Request الكاملة عبر Developer Flow

سرّعت الذكاء الاصطناعي من كتابة الأكواد، لكنها لم تحسّن العمل حول طلبات الدمج. لا يزال المطورون يعينون المراجعين، ويعالجون التعليقات عبر جولات متعددة، ويحلون التضاربات، ويعيدون تأسيس الفروع قبل الدمج. انتقلت الاختناق من الكود إلى العملية، لكن الأدوات لم تتكيف. GitLab 19.0 يغير ذلك.

Developer Flow يعمل على كامل دورة MR

سابقاً، كان Developer Flow يحل مهمة واحدة: تحويل issue إلى merge request. لقد أتمتة الإعداد الروتيني بين "ما يجب فعله" و "إليك MR للمراجعة". لكنها كانت مهمة واحدة فقط، وبمجرد فتح MR، كان كل شيء آخر يدويًا — تعليقات دائرية، تضاربات، إعادة بناء الفروع. الآن يعمل نفس النواة الذكية للوكيل على كامل دورة حياة MR. يمكنك تشغيله من أي مرحلة: من issue بزر Generate MR، أو تعيين حساب خدمة Duo Developer مباشرة على issue أو MR، أو ببساطة كتابة @mention في أي تعليق. يلتقط الوكيل سياق المحادثة ويعمل على نفس MR بدلاً من إنشاء واحد جديد.

ما بالضبط يفعله الوكيل:

• يعالج تعليقات المراجعين عبر جولات متعددة في MR واحد
• يحل تضاربات الدمج على الفروع طويلة الأمد
• يستكشف قواعد الأكواد غير المألوفة ويوصي بالطرق
• يقسم MRs الكبيرة جداً إلى أجزاء منطقية
• ينفذ ميزات جديدة من الصفر

تحت الغطاء، يعمل Developer Flow كحلقة وكيل واحدة مع مجموعة كاملة من أدوات المطور: قراءة الملفات، grep، التحرير، وتنفيذ الأوامر. يقرر الوكيل بنفسه أي أداة يستخدمها ومتى. هذا هو الأساس المعماري الذي يسمح لوكيل واحد بالمشاركة في جميع أنحاء دورة MR.

كيف يتعلم الوكيل عن مشروعك

هذه هي اللحظة الحاسمة التي تميز Developer Flow عن أدوات الذكاء الاصطناعي الأخرى للأكواد. يقرأ الوكيل AGENTS.md — ملف يصف أوامر bash غير الواضحة واتفاقيات المشروع وخصوصيات البيئة والقرارات المعمارية. مع agent-config.yml، يتلقى الوكيل بيئة تحتوي على المتطلبات الصحيحة والأدوات والتكوين. يمكنه تشغيل الاختبارات واستدعاء pre-commit hooks وإغلاق الحلقة قبل الالتزام. أنت تعطي الوكيل جهازاً يعرف معاييرك، والنتيجة تلبي المتطلبات بدلاً من إنشاء عمل إضافي.

حل التضاربات والخطوة الأخيرة

تضارب الدمج هو واحد من أكثر المهام إيلاماً في عملية MR. تحتاج إلى الحفاظ على نية كلا الفرعين في الاعتبار في نفس الوقت، وتحليل التغييرات في محرر نصوص دون تشغيل الاختبارات. كلما زادت قاعدة الأكواد، زادت احتمالية ظهور أخطاء في الحل اليدوي. بالنسبة للفرق التي تعمل مع backports و MRs المتسلسلة عبر فروع الإصدار المختلفة، إنها ضريبة ثابتة على السرعة.

يضيف GitLab 19.0 زراً Resolve with Duo (في الإصدار التجريبي): يقرأ الوكيل نية MR، وينظر إلى كلا الفرعين، ويختار استراتيجية الحل، ويحرر الملفات ويدفع النتيجة. يترك تعليقاً مع ملخص التضارب ومسار الحل — لا يحتاج المراجع التالي إلى إعادة بناء الحل، وتبقى مسار التدقيق سليمة. بشكل منفصل، بالنسبة لنهاية عملية MR، تمت إضافة ميزة one-click rebase and merge (أيضاً في الإصدار التجريبي). سابقاً، بالنسبة للفرق ذات السجل شبه الخطي، كانت: rebase، ثم merge. الآن إنه نقرة واحدة.

فئة جديدة من الأدوات

هذا جزء من تحول أوسع في عالم أدوات تطوير الذكاء الاصطناعي. الموجة الأولى سرعت من كتابة الأكواد. أضافت الموجة الثانية نافذة محادثة. الآن يتم إنشاء وكلاء يشاركون في عملية العمل بدلاً من المساعدة في لحظة واحدة. يوضح Developer Flow هذا النموذج: يبقى المطور فوق الدورة، ويدير ويراجع، بينما ينفذ الوكيل العمل.