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

تصوير تحريري لبنية تحتية سحابية تفصل بين قراءة المستودعات وتنسيق عمليات الكتابة في Git.

هذا تغيير كبير في البنية التحتية، لكنه ليس ميزة جديدة يستطيع المستخدمون تفعيلها. وتعرض GitHub هذا العمل بوصفه إعادة بناء مستمرة تُنفَّذ بينما تظل المنصة قيد التشغيل. ووفقًا للتدوينة اللاحقة، نقلت الشركة بالفعل نسخًا من 99.99999% من مستودعاتها إلى Azure، بينما تتطلب الحالات الطرفية المتبقية تغييرات في بروتوكول الكتابة. كما تعرض التدوينات تحسينات داخلية في معدل النقل، لكنها لا تنشر تفاصيل كافية عن المعايير المرجعية للتعامل مع هذه الأرقام باعتبارها ضمانًا للسعة لدى مؤسسة أو أسطول وكلاء بعينه.

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

ما الذي تغيّره GitHub

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

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

تتبع إعادة تصميم GitHub مبدئين مترابطين: نسّق فقط ما يجب تنسيقه، وافصل التخزين الدائم عن الحوسبة التي تخدم الطلبات.

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

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

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

لماذا كشفت أعباء الوكلاء عن عنق الزجاجة القديم

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

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

تقول GitHub إن نشاط Git الشهري نما من 218.2 مليار حدث في سبتمبر 2025 إلى 473.3 ملياراً في أغسطس 2026. وتذكر الشركة أيضاً تسجيل 7.38 مليار التزام في سبتمبر، و3.35 مليار عملية دفع شهرية، ونمواً يقارب أربعة أضعاف في عمليات دمج طلبات السحب، إضافة إلى 3.26 مليار عملية تشغيل لـ GitHub Actions خلال ذلك الشهر. تصف هذه الأرقام إجمالي نشاط المنصة، ولا تمثل قياساً صافياً للنشاط الذي تسببه الوكلاء وحدهم. فهي تشمل عمل المطورين التقليدي، والتكامل المستمر، والأتمتة، ونمو عدد العملاء. ومع ذلك، توضح سبب إعادة النظر في خدمة مستودعات صُممت لمستوى أقل من التزامن.

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

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

التنسيق لكل مرجع هو التفصيل التصميمي المهم

أهم تفصيل تقني في أحدث شرح من GitHub هو الانتقال من التنسيق على مستوى المستودع إلى التسلسل لكل مرجع.

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

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

تقول GitHub إن الاختبارات الداخلية للنهج الجديد أظهرت أن عمليات الكتابة إلى مراجع مختلفة حققت إنتاجية أعلى بنحو 3–4 مرات مع زمن استجابة أقل، وذلك في سيناريو الترحيل الذي وصفته الشركة. وهذه النتيجة أكثر تحديداً من رقم «إنتاجية كتابة أعلى بما يصل إلى 35 مرة» الوارد في منشور معماري سابق، لكن كلا الرقمين يظل قياسات داخلية. ولا تقدم المواد المنشورة معلومات كافية عن حجم المستودع، أو التزامن، أو مزيج أحمال العمل، أو العتاد الأساسي، أو النسب المئوية لزمن الاستجابة، أو نطاق الإطلاق في بيئة الإنتاج، بما يسمح لفريق خارجي بتحويل الأرقام مباشرة إلى معادلة لتحديد السعة.

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

التخزين الدائم وتوسيع نطاق القراءة

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

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

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

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

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

تحتاج أرقام «35 ضعفًا» إلى قراءة متأنية

يقول منشور GitHub السابق إن البنية المعاد بناؤها حققت في الاختبارات المعيارية الداخلية إنتاجية كتابة أعلى بما يصل إلى 35 ضعفًا. وهذه إشارة مفيدة إلى اتجاه العمل، لكنها لا تعني أن مستودعًا لدى أحد العملاء سيشهد تحسنًا بمقدار 35 ضعفًا.

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

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

والخلاصة التشغيلية واضحة: لا تحدد حجم منصة الوكلاء عبر ضرب التزامن الحالي في نتيجة الاختبار المعياري المعلنة. تعامل مع الاختبار بوصفه دليلًا على أن GitHub تعالج عنق زجاجة بنيويًا، ثم قِس عبء العمل الخاص بك من خلال زمن الدفع، وعمليات الدفع المرفوضة أو المعاد تنفيذها، وحدود معدل واجهة API، ووقت الانتظار في الطوابير، وانتشار عمليات CI، والمدة اللازمة للدمج.

ماذا يعني هذا لفرق الهندسة الآن

لا يحتاج المستخدمون إلى إعادة كتابة سير عمل Git المعتاد بسبب الإعلان. فهدف GitHub المعلن هو الحفاظ على التفريع، والمراجعة، والدمج، والسجل، وحماية الفروع، والمراجعات المطلوبة، وسجلات التدقيق، وإظهار المستودعات، وغيرها من الضوابط، مع تغيير الواجهة الخلفية التي تخدمها.

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

خفّض تكرار عمليات الدفع غير الضرورية

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

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

تجنّب إنشاء مرجع واحد ساخن

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

استخدم قوائم انتظار الدمج والتجميع المنضبط عندما يساعدان في تحسين الترتيب، لكن راقب عمر قائمة الانتظار وسلوك إعادة المحاولة. فقائمة الانتظار التي تعيد حساب المجموعة الكبيرة نفسها من التغييرات أو تعيد التحقق منها باستمرار قد تنقل الضغط من عمليات كتابة Git إلى CI أو واجهات برمجة تطبيقات طلبات السحب أو بنية الاختبار.

اجعل قراءات CI مقصودة

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

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

امنع سلوك إعادة المحاولة من تضخيم الحادثة

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

ينبغي لسياسة إعادة المحاولة أن تراعي المراجعة البشرية أيضًا. فإذا كان سير العمل ينتظر تحديث فرع محمي، فإن إعادة المحاولة العمياء قد تغمر المرجع نفسه بالطلبات بينما يحقق أحد المشغلين في المشكلة. التراجع وسيلة لضبط الموثوقية، وليس مجرد تحسين لأداء العميل.

حافظ على الحوكمة مع زيادة الأتمتة

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

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

ما يزال مجهولًا

لا تزال عدة أسئلة مهمة مفتوحة في الوصف العلني الذي قدمته GitHub.

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

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

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

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

القراءة العملية للإعلان

تستجيب GitHub لتغير حقيقي في طبيعة تطوير البرمجيات: عمليات أكثر على المستودعات، وفروع متزامنة أكثر، وقراءات آلية أكثر، وضغط متزايد على نقاط التكامل المشتركة. ويتمثل رد الشركة في تقليل التنسيق غير الضروري، وفصل التخزين الدائم عن حوسبة تقديم الخدمة، وجعل سعة القراءة مستقلة عن نصاب الكتابة حيثما أمكن.

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

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