تم إعداد ترجمة لهذه المادة لطلاب دورة ممارسات وأدوات DevOps في مشروع OTUS التعليمي.

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

لماذا نتحدث عن هذا؟

كتب مات كلاين مقالاً ، "Monorepos: من فضلك لا تفعل!" (تعليق المترجم: الترجمة على محور "المستودعات الإحيائية: من فضلك لا" ). أحب مات ، أعتقد أنه ذكي جدًا ، ويجب عليك قراءة وجهة نظره. قام في الأصل بتغريد الاستطلاع:

الترجمة:
في يوم رأس السنة الجديدة ، سوف أجادل حول مدى سخافة المستودعات الاحتكارية. 2019 بدأ دون أن يلاحظها أحد. بروح هذا ، أنا أقدم لكم مسحًا. من هم المتعصبين الكبار؟ أنصار:
- Monorepository
- الصدأ
- مسح خاطئ / كل من هؤلاء وتلك

كان جوابي: "أنا حرفيًا كل من هؤلاء الأشخاص." بدلاً من التحدث عن أي نوع من أنواع أدوية Rust ، دعونا نتعرف على سبب اعتقادي أنه مخطئ في المستودعات الأحادية. قليلا عن نفسك. أنا مدير قسم البرامج في الشيف. لدينا حوالي 100 مهندس ، قاعدة كود من حوالي 11-12 سنة ، و 4 منتجات رئيسية. جزء من هذا الكود موجود في مستودع البيانات (موضع البدء) ، وجزء في مستودع التخزين (موضع عملي الحالي).

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

وأنا أتفق مع الجزء الأول من وجهة نظر مات:

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

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

أعتقد أن حجة مات تشبه الآراء التي يشاركها العديد من المهندسين (والمديرين) والتي أحترمها. يحدث هذا من وجهة نظر المهندس الذي يعمل على المكون ، أو من الفريق الذي يعمل على المكون. تسمع أشياء مثل:

• قاعدة الشفرة مرهقة - لا أحتاج إلى كل هذه المهملات.
• هذا أصعب للاختبار لأنني يجب أن أتحقق من كل هذا غير المرغوب فيه الذي لا أحتاج إليه.
• من الأصعب العمل مع التبعيات الخارجية.
• أحتاج إلى أنظمة التحكم في الإصدار الظاهري الخاصة بي.

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

إنه يثير التواصل ويظهر المشاكل.

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

مع تعقيد الهندسة المعمارية ، لم يعد بإمكان فريق واحد إدارته بمفرده. عدد قليل جدا من المهندسين يحتفظون بالنظام بأكمله. لنفترض أنك تتحكم في مكون شائع A ، والذي تستخدمه الأوامر B و C و D. يعيد تكوين فريق A ، ويحسن واجهة برمجة التطبيقات ، ويغير أيضًا التنفيذ الداخلي. نتيجة لذلك ، التغييرات إلى الوراء غير متوافقة. ما النصيحة التي تقدمها؟

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

يرجى ملاحظة أن هذه الأسئلة مستقلة عن نوع المستودع. ستحتاج إلى إيجاد فرق B و C و D. ستحتاج إلى التحدث معهم ومعرفة الوقت وفهم أولوياتهم. على الأقل نأمل أن تفعل ذلك.

لا أحد يريد فعل ذلك. هذا أقل متعة بكثير من مجرد إصلاح API لعنة. كل هذا إنسان ومربك. في المستودع ، يمكنك ببساطة إجراء تغييرات ، وتقديم مراجعة لأولئك الذين يعملون على هذا المكون (ربما لا يكون B أو C أو D) ، والمضي قدمًا. يمكن للفرق B و C و D البقاء ببساطة على نسختها الحالية. سيتم تحديثها عندما يدركون عبقريتك!

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

ثم نحتاج إلى التحدث عن كيفية الخروج من هذا الموقف:

1. دعم واجهات برمجة التطبيقات الداخلية متعددة ، في حين سيتم وضع علامة الخوارزمية القديمة عفا عليها الزمن حتى D يمكن التوقف عن استخدامه.
2. دعم إصدارات متعددة من الإصدارات ، واحد مع الواجهة القديمة ، واحد مع الجديد.
3. تأخر إصدار التغييرات على A حتى يقبلها B و C و D.

لنفترض أننا حددنا 1 ، عدة واجهات برمجة التطبيقات. في هذه الحالة ، لدينا قطعتين من التعليمات البرمجية. القديم والجديد. مفيد جدا في بعض الحالات. نرجع الرمز القديم إلى الوراء ونضع علامة عليه على أنه متقادم ونتفق على جدول زمني لإزالته باستخدام الأمر D ، وهو مطابق تمامًا لـ poly وللمتحف.

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

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

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

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

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