يقترح GitHub أسلوباً عملياً لإدارة تغييرات البرمجيات عبر دورة التسليم كاملة من داخل المنصة، باستخدام تطبيقات وكلاء يمكن استدعاؤها من تبويب Agents أو عبر التعليقات في طلبات السحب. الفكرة ليست استبدال Amplitude أو Endor Labs أو LaunchDarkly أو PagerDuty، بل جلب السياق الذي توفره هذه الخدمات إلى المكان الذي يعمل فيه المطورون بالفعل، بحيث تنتقل المهمة من الفكرة إلى الإنتاج من دون تبديل الأدوات أو إعادة نقل المعلومات بينها يدوياً.
يعتمد المثال الذي يقدمه GitHub على تعديل في مسار التسجيل التجريبي لمنتج ما، يتمثل في جعل خطوة «دعوة زملائك» اختيارية. كانت فرق الدعم تعتبر الخطوة مصدر احتكاك للمستخدمين، لكن هذا الانطباع لا يكفي وحده لتحديد التغيير الصحيح. لذلك يقسم سير العمل إلى أربع نقاط تحقق قبل البناء وأثناءه وقبل الإطلاق والنشر.
1. التحقق من الحاجة قبل كتابة الكود
بدلاً من فتح Amplitude وبناء استعلام منفصل، يمكن طلب التحليل من وكيل Amplitude مباشرة عبر تبويب Agents. في المثال، يُطلب من الوكيل التحقق مما إذا كان إكمال خطوة دعوة أعضاء الفريق يرتبط بالنجاح في مراحل لاحقة من مسار التسجيل، مع تقسيم النتائج حسب الشرائح التي يجري قياسها.
تظهر النتيجة اختلافاً بين نوعين من المستخدمين: المستخدمون الذين يسجلون كفرق ويكملون الخطوة يكونون أكثر ميلاً إلى الاحتفاظ بهم لاحقاً، في حين لا يظهر الارتباط نفسه لدى المستخدمين الأفراد. بناءً على ذلك، يصبح من المنطقي إعادة تحديد نطاق التغيير بدلاً من حذف الخطوة للجميع: تُؤجل الخطوة في تسجيلات المستخدمين الأفراد، بينما تبقى للمستخدمين الذين يسجلون كفرق.
أهمية هذه المرحلة أن قرار المنتج يُراجع قبل استثمار وقت التطوير. فالملاحظة الواردة من الدعم تتحول إلى فرضية قابلة للفحص داخل GitHub، ثم إلى نطاق أكثر دقة للتنفيذ.
2. فحص الاعتماديات أثناء تنفيذ التغيير
بعد أن ينشئ Copilot طلب سحب مسودة للتعديل، قد تشمل عملية التنفيذ تحديث اعتماديات يستخدمها مسار التسجيل. بدلاً من انتظار فشل فحص مستمر للتكامل لاحقاً، يمكن استدعاء وكيل Endor Labs في تعليق داخل طلب السحب للسؤال عن المخاطر المرتبطة بالاعتماديات التي تمسها التغييرات.
يفحص الوكيل الاعتماديات المتغيرة بحثاً عن الثغرات المعروفة ومخاطر الحزم الأوسع، ثم يعرض النتيجة داخل طلب السحب. وفي المثال، لم يجد الوكيل ما يحتاج إلى معالجة، ما سمح باستكمال المراجعة من دون تأجيل اكتشاف المشكلة إلى مرحلة لاحقة من خط أنابيب التكامل المستمر.
بهذا الأسلوب، تصبح مراجعة الاعتماديات خطوة استباقية مرتبطة مباشرة بالكود الجاري مراجعته، بدلاً من أن تكون مهمة إصلاح تبدأ بعد فشل فحص آلي.
3. طرح التغيير تدريجياً باستخدام علامة ميزة
بعد تنفيذ المسار المختلف للمستخدمين الأفراد والفرق، يمكن استخدام علامة ميزة تستهدف الشرائح المحددة عند التسجيل. يطلب المطور من وكيل LaunchDarkly إنشاء العلامة وربطها بالكود، مع تحديد المعلمات التالية:
- المفتاح: defer-team-invite.
- النوع: منطقي.
- القيمة الافتراضية: false.
- الاستهداف: تسجيلات ذات نية فردية.
- التدرج: داخلي، ثم 5%، ثم 25%، ثم 100%.
ينشئ الوكيل العلامة في LaunchDarkly ويضيف تنفيذها إلى الكود في صورة التزام يمكن للمطور مراجعته. وإذا كانت البيئة المستهدفة تتطلب موافقة، ينشئ الوكيل طلب موافقة بدلاً من تطبيق تغيير الاستهداف مباشرة. تظل خطوة تقدم الإطلاق قراراً بشرياً، ولا يتحول الوكيل إلى جهة تقرر وحدها الانتقال بين مراحل الطرح.
يختصر هذا المسار إعداد العلامة، وتسليم التغيير إلى الكود، والتنسيق بين الأدوات في تعليق واحد داخل طلب السحب والتزام يخضع للمراجعة.
4. تقييم مخاطر النشر قبل الدمج
نجاح مراجعة الكود لا يجيب بالضرورة عن سؤال مختلف: هل حالة الخدمة مناسبة للنشر الآن؟ قبل الدمج، يمكن استدعاء وكيل PagerDuty لتقييم مخاطر نشر طلب السحب مقابل خدمة التسجيل، والتحقق من الحوادث النشطة وسجل الحوادث الحديث، ثم تقديم توصية بشأن المضي قدماً.
يربط الوكيل المستودع بخدمة PagerDuty المقابلة، ويتحقق من الحوادث النشطة، ويراجع سجل الأيام التسعين السابقة، ثم يقارن الملفات المتغيرة في طلب السحب بالمناطق التي ارتبطت بحوادث سابقة. في المثال، كان مستوى المخاطر منخفضاً؛ إذ لم توجد حوادث نشطة، ولم يظهر ارتباط مهم بين التغييرات الحالية والحوادث السابقة، لذلك كانت التوصية هي المتابعة.
المغزى العملي هنا أن تقييم مخاطر النشر يصبح إجراءً اعتيادياً ضمن طلبات السحب، لا خطوة لا تُستدعى إلا عندما يبدو الإصدار خطيراً مسبقاً.
كيفية استخدام تطبيقات الوكلاء
تتوفر تطبيقات الوكلاء عبر GitHub Marketplace. وبعد تثبيت التطبيق وتمكينه للمؤسسة، يذكر GitHub ثلاث طرق لاستخدامه داخل سير العمل:
- إسناده إلى مسألة لبدء مهمة.
- الإشارة إليه في تعليق على طلب سحب لإجراء تحليل أو تنفيذ إجراء.
- اختياره من تبويب Agents في المستودع.
ويشير GitHub إلى تطبيقات أخرى ضمن الدفعة الأولى، منها وكيل Packfiles الذي يقرأ قائمة الأعمال ويبني استراتيجية للترحيل، ووكيل Miro الذي يربط التعاون المرئي بسير عمل الكود، ووكيل Bright Security الذي يتولى اختبار الأمن الديناميكي الشامل داخل GitHub، ووكيل SonarQube الذي يجلب التحليل وبوابات الجودة والمعالجة إلى جلسات وكلاء GitHub، إضافة إلى وكيل Octopus Deploy القادر على تحديد أعطال النشر وتشخيصها وحلها.
وفق هذا النموذج، تبقى الخدمات والأدوات التي تعتمد عليها الفرق موجودة، لكن سياقها يظهر داخل سير عمل GitHub. ويتيح ذلك للمطور استدعاء القدرة المناسبة في اللحظة التي يحتاجها فيها، مع إبقاء نتائج التحليل والتغييرات وطلبات الموافقة ضمن مسار يمكن مراجعته.