مستودعات أحادية: من فضلك لا (الجزء 2)

مرحبا بالجميع!

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

سأخبركم قليلاً عن نفسي - لقد عملت في كل من المشروعات الصغيرة والمشاريع الكبيرة نسبيًا ، واستخدمت مستودعات متعددة في مشروع يحتوي على أكثر من 100 خدمة ميكروية (و SLA 99.999٪). في الوقت الحالي ، أشارك في ترجمة مستودع صغير أحادي (في الواقع لا ، فقط js + java backend الخلفية) من maven إلى bazel. لم يعمل على Google و Facebook و Twitter ، أي ليس من دواعي سروري استخدام مستودع أحادي تم تكوينه وضبطه بشكل صحيح.

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

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

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

ما هي المشكلة إذن؟ والمشكلة ، كما لوحظ في المقال الأصلي ، تبدأ على نطاق معين. والأهم من ذلك ، لا تفوت لحظة وصول مثل هذا النطاق بالفعل.

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

لذا ، ما حجم مستودع التخزين للبدء في اعتباره مشكلة؟
من المؤكد أن هناك مؤشرين يعتمدان على ذلك - مقدار الكود وعدد المطورين الذين يعملون مع هذا الكود. إذا كان مشروعك يحتوي على تيرابايت من التعليمات البرمجية ، ولكن يعمل من شخص إلى آخر معه ، فمن المرجح ألا يلاحظوا أي مشكلات تقريبًا (جيدًا ، أو على الأقل سيكون من الأسهل عدم القيام بأي شيء ، حتى لو لاحظوا :)

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


الآن ، دعنا ننتقل إلى قائمة المشاكل التي تنشأ في مستودعات كبيرة (تم ذكر بعضها في المقالة الأصلية ، وبعضها غير مذكور).

1) مستودع وقت التحميل

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

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

2) بناء الوقت

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

لا توجد خيارات كثيرة هنا - على الرغم من حقيقة أن ميزات التخزين المؤقت تمت إضافتها إلى نفس المجال (لسوء الحظ ، لم أستخدمها في الممارسة) ، فإنها لا تحقق فائدة عملية بسبب حقيقة أن أنظمة الإنشاء التقليدية لا تتمتع بنتائج قابلة للتكرار (يبني استنساخه). أي نظرًا للتأثيرات الجانبية للمبنى السابق ، على أي حال ، سيكون من الضروري في وقت ما استدعاء تنظيف ذاكرة التخزين المؤقت (نهج maven clean build القياسية). لذلك ، يبقى فقط خيار استخدام Bazel / Buck / Pants وغيرهم من أمثالهم. لماذا هذا ليس جيدا جدا ، وسوف نناقش في وقت لاحق قليلا.

3) فهرسة IDE

تتم فهرسة مشروعي الحالي في Intellij IDEA لمدة 30 إلى 40 دقيقة. ماذا عنك؟ بالطبع ، يمكنك فتح جزء فقط من المشروع أو استبعاد جميع الوحدات غير الضرورية من الفهرسة ، ولكن ... المشكلة هي أن إعادة الفهرسة تحدث في كل مرة تقوم فيها بالتبديل من فرع إلى آخر. لهذا السبب أحب استنساخ مشروع في دليل مجاور. يبدأ بعض الأشخاص في تخزين ذاكرة التخزين المؤقت IDE :)
<صورة دي كابريو بعيون ضيقة>

4) بناء السجلات

ما خادم CI الذي تستخدمه؟ هل يوفر واجهة مريحة لعرض العديد من غيغابايت من سجلات البناء والتنقل فيها؟ لسوء الحظ ليس لي :(

5) تاريخ ارتكابها

هل تحب مشاهدة التزام التاريخ؟ أحب ، خاصةً في أداة ذات واجهة رسومية (أرى المعلومات أفضل بصريًا ، لا تأنيب :).

هل اعجبك هل هي مريحة؟ أنا شخصياً لا أفعل!

6) اختبارات مكسورة

ماذا يحدث إذا تمكن شخص ما من إجراء اختبارات مقطوعة / شفرة غير مجمعة في برنامج الماجستير؟ ستقول بالتأكيد أن CI الخاص بك لا يسمح لك بالقيام بذلك. ماذا عن الاختبارات غير المستقرة التي يمر بها المؤلف ، ولا أحد غيره؟ الآن تخيل أن هذا الرمز امتد إلى آلات 300 مطور ، ولا يستطيع أي منهم تجميع مشروع؟ ماذا تفعل في مثل هذه الحالة؟ انتظر المؤلف لإشعار وتصحيح؟ صحيح بالنسبة له؟ استرجاع التغييرات؟ بطبيعة الحال ، من الناحية المثالية ، فإنه يستحق ارتكاب رمز جيد فقط ، والكتابة على الفور دون أخطاء. ثم لن تنشأ مثل هذه المشكلة.
(بالنسبة لأولئك الذين لم يفهموا التلميحات الموجودة في الخزان ، الحديث عن التأثير السلبي إذا حدث ذلك في المستودع مع 10 مطورين وفي المستودع الذي يحتوي على 300 سيكون مختلفًا قليلاً)

7) دمج الروبوت

هل سمعت عن شيء من هذا القبيل؟ هل تعرف لماذا تحتاجها؟ سوف تضحك ، ولكن هذه أداة أخرى لا ينبغي أن تكون موجودة :) فقط تخيل أن وقت بناء مشروعك هو 30 دقيقة. ويعمل 100 مطور في مشروعك. لنفترض أن كل منهم يدفع التزامًا واحدًا يوميًا. الآن تخيل CI صادقًا ، والذي يسمح لك بدمج التغييرات في الرئيسية فقط بعد تطبيقها على الالتزام الأخير من الرئيسي (rebase).

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

لذا ، فإن دمج bot أو merge queue هي خدمة تقوم بأتمتة عملية إعادة تخصيص جميع طلبات الدمج الخاصة بسيد جديد ، وإجراء الاختبارات ودمجها ، ويمكنها أيضًا الجمع بين الالتزامات في دفعات واختبارها معًا. شيء مفيد جدا. راجع mergify.io ، k8s test-infra Prow من Google ، bors-ng ، وما إلى ذلك (أعدك بكتابة المزيد حول هذا الموضوع في المستقبل)

الآن للمشاكل التقنية الأقل:

8) باستخدام أداة بناء واحدة

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

بالطبع ، يبدو من الواضح أن استخدام نظام بناء واحد أفضل من العديد من الأنظمة المختلفة. لكنهم ما زالوا يفهمون أن أي شيء عالمي هو أسوأ من كونه متخصصًا ، لأنه على الأرجح يحتوي فقط على مجموعة فرعية من وظائف جميع المتخصصة. ولكن الأسوأ من ذلك ، قد يكون للغات البرمجة المختلفة نماذج مختلفة من حيث التجميع ، وإدارة التبعية ، وما إلى ذلك ، والتي سيكون من الصعب للغاية لفها في غلاف مشترك واحد. لا أريد الخوض في التفاصيل ، سأقدم مثالًا واحدًا على bazel (راجع التفاصيل في مقالة منفصلة) - وجدنا 5 تطبيقات مستقلة لقواعد تجميع javascript لـ bazel من 5 شركات مختلفة على GitHub ، بالإضافة إلى المثال الرسمي من Google. الأمر يستحق النظر.

9) النهج العامة

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

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

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

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

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

10) المصدر المفتوح

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

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

البدائل

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

ما هي عيوب النهج متعدد المستودعات؟ أرى بالضبط 1: عدم القدرة على تتبع من هو المستهلك لواجهة برمجة التطبيقات. وينطبق ذلك بشكل خاص على النهج المتبع في "مشاركة أي شيء" في الخدمات المصغرة ، حيث لا يتم تخريب الرمز بين الخدمات الصغيرة. (بالمناسبة ، هل تعتقد أن أي شخص يستخدم هذا النهج في مستودعات أحادية؟) لسوء الحظ ، يجب حل هذه المشكلة إما عن طريق وسائل تنظيمية ، أو محاولة استخدام أدوات تصفح التعليمات البرمجية التي تدعم المستودعات المستقلة (على سبيل المثال ، https://sourcegraph.com / ).

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

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

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

بدلاً من الاستنتاج:

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

وإلى أي شخص آخر: "أنت لست Google ، لا تستخدم المستودعات الأحادية!"

ص. كما لاحظ بوبوك المحترم في إذاعة T-Radio عند مناقشة المقال الأصلي: "هناك حوالي 20 شركة في العالم يمكنها استخدام مستودع واحد. يجب ألا يحاول الباقي ".