OpenAI تسرّع إرسال التغييرات إلى Git بنحو خمس مرات بفضل Pando

أنهى الوكيل تعديله، لكن الاختبارات لم تبدأ بعد: فأولًا يجب إرسال التغييرات وتنزيل الشيفرة إلى بيئة الفحص. ومع عشرات المهام المتوازية، قد يلتهم انتظار Git جزءًا من المكسب الناتج عن سرعة توليد الشيفرة. وتفيد قصة Pando الفرق التي تزيد عدد وكلائها وتريد معرفة أين تظهر الطابور التالي.

ما الذي عرضته OpenAI

في تحليل تقني بتاريخ 2 نوفمبر وصفت OpenAI نظام Pando، وهو الواجهة الخلفية الداخلية لـ Git. وتذكر الشركة أن الزمن الوسيط لعملية push انخفض بنحو خمس مرات، وأنها توزع ما يقارب بيتابايت من بيانات Git يوميًا. وقد بقي التوافق مع عميل Git وبروتوكوله.

يقوم النظام على قرارين: تحديثات مستقلة لفروع مختلفة، وإعادة استخدام حزم البيانات الجاهزة عند القراءة. لكن قراءة عدة فروع لا تضمن لقطة واحدة للمستودع كله في لحظة زمنية واحدة. ويعمل Pando داخل OpenAI؛ وتدرس الشركة سبل مشاركة التقنية، لكنها لا تحدد موعدًا للإصدار.

من الناحية العملية، تهم حدود القياس. فالوسيط في عمليات push يصف الزمن النموذجي لعملية واحدة، ولا يمكن منه حساب مدى سرعة إصدار الفريق لمنتجه. فبين إرسال التغييرات والإصدار تبقى الاختبارات والمراجعات والإصلاحات والموافقات. والتسارع بنحو خمس مرات في هذه المرحلة لا يعني وحده تسارعًا مماثلًا في التطوير.

مثال: وكلاء يجهزون عدة تعديلات

لنتخيل فريق متجر إلكتروني. وكيل يعدّل البحث، وثانٍ يصلح سلة المشتريات، وثالث يحدّث التبعيات. كل منهم يعمل في فرعه. بعد إرسال التغييرات، يجب على نظام الفحص الحصول على النسخة المطلوبة من الشيفرة وتشغيل الاختبارات. وإذا بدأت الفحوص في وقت واحد، فإن عدة قارئين يصلون إلى تاريخ المستودع نفسه.

يتيح تقسيم العمل على الفروع التعامل مع هذه العمليات بشكل منفصل. فتعديل البحث لا يلزمه انتظار تحديث السلة لمجرد أن كليهما في مستودع واحد. أما إعادة توزيع حزمة جاهزة فتشبه إرسال الأرشيف نفسه إلى عدة مستلمين: من مصلحة الخادم استخدام بيانات أُعدّت مسبقًا. وهذا توضيح مبسّط لمبدأين من مبادئ Pando، وليس وصفًا لبنية متجر فعلي.

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

وثمة نتيجة تخص الأتمتة أيضًا. فإذا اتخذت العملية قرارًا بناءً على عدة فروع دفعة واحدة، فيجب تحديد النسخ التي تقارنها بوضوح. فمثلًا، يجب أن يثبّت فحص توافق تعديلين إيداعات (commits) محددة. وإلا فقد تفحص إعادة التشغيل توليفة أخرى من الشيفرة، ويصعب على المطوّر إعادة إنتاج النتيجة.

ما الذي يمكن فحصه لديكم

يمكن البدء بقياس مهمة كاملة واحدة: من التعديل الجاهز حتى نتيجة الفحص. قسّموا الوقت إلى إرسال التغييرات، والحصول على الشيفرة، وانتظار منفّذ متاح، والاختبارات نفسها. سيُظهر هذا التحليل أي مرحلة تبطئ العمل فعلًا. وإذا كان التأخير الرئيسي في طابور الاختبارات، فإن استبدال خادم Git سيكون أثره محدودًا.

ثم كرّروا القياس عند توازٍ عادي وعند الذروة. فما يهم الفريق هو اللحظة التي يتوقف فيها الوكلاء الإضافيون عن تقليص زمن إنجاز المهام. ومن المفيد النظر إلى الأزمنة النموذجية وإلى حالات الانتظار الطويلة النادرة، فهذه الأخيرة هي التي قد تؤخر إصلاحًا عاجلًا. ويجب مقارنة النتائج على مهام متطابقة وبعدد متساوٍ من الفحوص.

وبالنسبة لمدير المنتج والمؤسس، ستساعد هذه البيانات على تقدير كلفة التسريع. فالوكيل الإضافي مفيد إذا قطع نتاجه المسار كله حتى تعديل مقبول. أما إذا كان ما يزداد هو عدد الفروع والفحوص غير المكتملة فقط، فالأجدر معالجة الطابور أولًا. والخلاصة العملية من Pando هي إدراج Git وتسليم الشيفرة في قياس أداء التطوير القائم على الوكلاء، ثم اتخاذ قرار البنية التحتية الجديدة بناءً على قياساتكم الخاصة.