كم علامة تبويب مفتوحة بجانب pull request؟
تخيّل أنك تعالج issue جديدة في مسار onboarding للتجربة المجانية لمنتجك: اجعل خطوة “invite your teammates” اختيارية. مع ازدياد أعداد التسجيلات، يواصل فريق الدعم الإشارة إلى هذه الخطوة باعتبارها نقطة احتكاك. مكسب سريع، أليس كذلك؟
من تحديد النطاق حتى deployment، تحتاج إلى إجابات عن الأسئلة الأربعة التالية:
هل هذا هو التغيير الصحيح فعلًا؟
هل التبعيات التي لمستها سليمة؟
كيف أطرح هذا التغيير للاستخدام بأمان؟
هل من الآمن إجراء deployment الآن؟
توجد كل إجابة في أداة مختلفة؛ وبالتالي، فإن العمل على pull request يعني نقل السياق نفسه بين أربعة أماكن مختلفة.
تجلب تطبيقات GitHub agent الأدوات التي تحتاج إليها للإجابة عن هذه الأسئلة إلى المكان الذي تعمل فيه بالفعل؛ وذلك على المنصة وبيئة التشغيل نفسيهما اللذين نستخدمهما مع Copilot cloud agent الخاص بنا.
يوضح المثال التالي كيفية استخدام خدمات تعتمد عليها بالفعل، مثل Amplitude وEndor Labs وLaunchDarkly وPagerDuty، للإجابة عن هذه الأسئلة وإكمال هذا الطلب من دون مغادرة GitHub على الإطلاق.
1. قبل بدء التطوير
يقول فريق الدعم إن خطوة “invite your teammates” مزعجة للعملاء الذين يدخلون في عملية onboarding مع منتجك؛ لكنه لم يقدم أي معلومات عن الأشخاص الذين يشتكون أو عما إذا كانت هذه الشكاوى تؤدي إلى فقدان العملاء. من الصواب أن تكون متشككًا. لذلك، بدلًا من فتح Amplitude وإنشاء استعلام للتحقق من فرضيتك، تسأل agent الخاص بـ Amplitude مباشرةً من علامة التبويب Agents:
@amplitude[agent] هل يرتبط إكمال خطوة دعوة الفريق بالنجاح في المراحل اللاحقة من funnel؟ قسّم النتائج وفقًا للشرائح التي نقيسها.
التمييز واضح: تكون احتمالية احتفاظ مستخدمي الفرق الذين يكملون الخطوة أعلى لاحقًا، بينما لا توجد علاقة مماثلة لدى المستخدمين الفرديين. لدينا الآن مبرر لإعادة تحديد النطاق: أجّلوا هذه الخطوة لمن يسجلون بشكل فردي، واحتفظوا بها للفرق.
أصبح الوصول إلى رؤى المنتج متاحًا الآن داخل GitHub، ما يتيح تصحيح المسار قبل كتابة أي تعليمات برمجية.
2. أثناء التطوير
يفتح Copilot مسودة pull request لإجراء التغيير. ويحدّث التطبيق أيضًا التبعيات المستخدمة في مسار onboarding. وبدلًا من انتظار فشل فحص CI لاحقًا، تسألون agent الخاص بـ Endor Labs في التعليق:
@endor-labs-github-agenthq[agent] هل هناك أي شيء يجب أن أنتبه إليه في التبعيات التي يمسّها هذا pull request؟
يحدد agent التبعيات التي جرى تغييرها، ويفحصها بحثًا عن الثغرات الأمنية المعروفة والمخاطر الأوسع المرتبطة بالحزمة، ثم يقدم تقريرًا في pull request. هذه المرة، يبدو كل شيء سليمًا. لا يوجد ما يحتاج إلى المعالجة.
تتحول مراجعة التبعيات إلى فحص استباقي بينما لا يزال التغيير أمامكم. وهذا أفضل بكثير من إجراء الإصلاح بعد فشل فحص CI.
3. الإطلاق
يُطبَّق الاكتشاف السابق الآن: يستخدم المسجلون بشكل فردي المسار الاختياري، بينما تحتفظ الفرق بالمسار الحالي. وبما أن هذه الشرائح تُحدَّد أثناء التسجيل، يمكن لعلامة ميزة استهدافها مباشرة. اطلبوا من agent الخاص بـ LaunchDarkly إعداد ذلك لكم، كما لو كنتم تطلبونه من أحد زملائكم في الفريق:
@launchdarkly-agent[agent] يرجى إنشاء علامة ميزة لهذا pull request وربطها بالكود.
– key: defer-team-invite
– type: boolean
– default: false
– target: تسجيلات ذات نية فردية
– rollout: داخلي > 5% > 25% > 100%
ينشئ Agent علامة الميزة في LaunchDarkly ويضيف تطبيق الكود في صورة commit لمراجعته. وإذا كانت البيئة المستهدفة تتطلب موافقة، فإنه ينشئ طلب موافقة بدلًا من تطبيق تغيير الاستهداف مباشرة. ويظل القرار بشأن مواصلة الإطلاق بيد شخص.
لم يعد إعداد العلامة المميزة عملية تتطلب أداة ثانية، ونقلًا يدويًا للكود، وتنسيقًا عبر Slack؛ بل أصبح تعليقًا واحدًا على pull request وcommit لمراجعته.
4. قبل الإطلاق
تُظهر المراجعة أن الكود صحيح، لكن ما إذا كانت الخدمة في حالة جيدة لعملية نشر فهو سؤال مختلف.