ترجمة المقال المعد لطلبة المقرر في المشروع التعليمي OTUS.
يجب عليك اختيار monorepo لأن السلوك الذي يروج له في فريقك هو الشفافية والمسؤولية المشتركة ، خاصة مع نمو الفرق. في كلتا الحالتين ، سيتعين عليك الاستثمار في الأدوات ، ولكن من الأفضل دائمًا أن يكون السلوك الافتراضي هو السلوك الذي تريد رؤيته في أوامرك.
لماذا نتحدث عن هذا؟
كتب مات كلاين مقالاً (ملاحظة المترجم: الترجمة عن حبري ). أنا أحب مات ، أعتقد أنه ذكي للغاية ويجب أن تقرأ وجهة نظره. نشر الاستطلاع في الأصل على Twitter:
ترجمة:
في يوم رأس السنة الجديدة ، سأناقش مدى سخافة المستودعات الأحادية. بدأ عام 2019 بهدوء. من هذا المنطلق ، أقدم لك استبيانًا. من هم المتعصبون الكبار؟ أنصار:
- المستودعات الأحادية
- Rust
- استطلاع خاطئ / كلاهما
كان إجابتي ، "أنا حرفياً كلا هذين الشخصين". بدلاً من الحديث عن نوع عقار Rust ، دعنا نلقي نظرة على سبب اعتقادي أنه مخطئ بشأن المستودعات الأحادية. قليلا عن نفسك. أنا مدير التكنولوجيا في برنامج Chef Software. لدينا حوالي 100 مهندس ، وقاعدة رمز لحوالي 11-12 سنة ، و 4 منتجات أساسية. بعض من هذا الكود موجود في التوضيع المتعدد (موضع البداية الخاص بي) ، والبعض الآخر في المستودع الأحادي (موقعي الحالي).
قبل أن أبدأ: كل حجة أقوم بها هنا ستنطبق على كلا النوعين من المستودعات. في رأيي ، لا يوجد سبب تقني لاختيار نوع واحد أو آخر من المستودعات. يمكنك جعل أي نهج يعمل. يسعدني التحدث عن ذلك ، لكنني لست مهتمًا بالأسباب التقنية المصطنعة التي تجعل أحدهما متفوقًا على الآخر.
أوافق على الجزء الأول من نقطة مات:
لأنه على نطاق واسع ، سيحل monorepo جميع المشكلات نفسها التي يحلها polyrepository ، ولكن في نفس الوقت يحثك على ربط الكود بإحكام ويتطلب جهودًا لا تصدق لزيادة قابلية نظام التحكم في الإصدار الخاص بك.
عليك أن تحل نفس المشاكل ، بغض النظر عما إذا كنت قد اخترت مستودع أحادي أو متعدد. كيف تفرجون عن الإصدارات؟ ما هو نهجك للتحديثات؟ التوافق؟ عبر تبعيات المشروع؟ ما هي الأنماط المعمارية المقبولة؟ كيف تدير البنية التحتية للبناء والاختبار؟ القائمة لا حصر لها. وسوف تحلها جميعًا أثناء نموك. لا يوجد جبن مجاني.
أعتقد أن حجة مات تشبه الآراء التي يشاركها العديد من المهندسين (والمديرين) التي أحترمها. هذا من منظور المهندس الذي يعمل على المكون ، أو الفريق الذي يعمل على المكون. تسمع أشياء مثل:
- قاعدة الشفرة مرهقة - لست بحاجة إلى كل هذه الخردة.
- من الصعب الاختبار لأن عليّ اختبار كل هذه الهراء التي لا أحتاجها.
- من الصعب العمل مع التبعيات الخارجية.
- أحتاج إلى أنظمة التحكم في الإصدار الافتراضي الخاص بي.
بالطبع ، كل هذه النقاط لها ما يبررها. يحدث هذا في كلتا الحالتين - لديّ خردة خاصة بي في التركيب المتعدد ، بالإضافة إلى ما هو مطلوب للبناء ... قد أحتاج إلى خردة أخرى. لذلك ، أقوم "فقط" بإنشاء أدوات تحقق من المشروع بأكمله. أو أقوم بإنشاء monorepo مزيف مع وحدات فرعية. يمكننا المشي طوال اليوم حول هذا. لكني أعتقد أن حجة مات تخطئ السبب الرئيسي ، الذي قلبته قليلًا لصالح monorepo:
إنه يثير التواصل ويظهر المشاكل
عندما نفصل بين المستودعات ، فإننا نخلق مشكلة فعلية تتعلق بالتنسيق والشفافية. يتماشى هذا مع طريقة تفكيرنا في الفرق (خاصةً كيف يفكر الأفراد بها): نحن مسؤولون عن مكون معين. نحن نعمل في عزلة نسبية. تم إصلاح الحدود على فريقي والمكونات التي نعمل عليها.
نظرًا لأن البنية تصبح أكثر تعقيدًا ، لم يعد بإمكان فريق واحد إدارتها بمفرده. عدد قليل جدًا من المهندسين يحتفظون بالنظام بأكمله في رؤوسهم. لنفترض أنك تدير مكونًا مشتركًا A يتم استخدامه من قبل الفرق B و C و D. يقوم الفريق A بإعادة البناء وتحسين واجهة برمجة التطبيقات وتغيير التنفيذ الداخلي. نتيجة لذلك ، لا تتوافق التغييرات مع الإصدارات السابقة. ما النصيحة التي تقدمها؟
- ابحث عن جميع الأماكن التي يتم فيها استخدام واجهة برمجة التطبيقات القديمة.
- هل هناك أماكن لا يمكن فيها استخدام واجهة برمجة التطبيقات الجديدة؟
- هل يمكنك إصلاح واختبار المكونات الأخرى للتأكد من عدم كسرها؟
- هل يمكن لهذه الأوامر اختبار تغييراتك الآن؟
لاحظ أن هذه الأسئلة مستقلة عن نوع المستودع. ستحتاج إلى العثور على الفرق B و C و D. ستحتاج إلى التحدث إليهم ، ومعرفة الوقت ، وفهم أولوياتهم. على الأقل نأمل أن تفعل.
في الواقع ، لا أحد يريد القيام بذلك. إنها أقل متعة بكثير من مجرد إصلاح واجهة برمجة التطبيقات (API) اللعينة. كل هذا بشري ومربك. في التركيب المتعدد ، يمكنك فقط إجراء تغييرات ، ومراجعتها من قبل أولئك الذين يعملون على هذا المكون (ربما ليس B أو C أو D) ، والمضي قدمًا. يمكن للفرق B و C و D البقاء في نسختهم الحالية في الوقت الحالي. سوف يقومون بالترقية عندما يدركون عبقريتك!
في الإيداع الأحادي ، يتم تحويل المسؤولية بشكل افتراضي. يغير فريق A مكونه ، وإذا لم يكن حريصًا ، فسيقوم على الفور بكسر B و C و D. وهذا يؤدي إلى ظهور B و C و D عند باب A ، متسائلاً عن سبب كسر فريق A للبنية. هذا يعلم أ أنه لا يمكنهم تخطي قائمتي أعلاه. يجب أن يتحدثوا عما سيفعلونه. هل يمكن أن يتحرك "ب" و "ج" و "د"؟ ماذا لو كان بإمكان B و C ، لكن D كان مرتبطين ارتباطًا وثيقًا بأثر جانبي لسلوك الخوارزمية القديمة؟
ثم يجب أن نتحدث عن كيفية الخروج من هذا الموقف:
- دعم العديد من واجهات برمجة التطبيقات الداخلية ، مع إيقاف الخوارزمية القديمة حتى يتمكن D من التوقف عن استخدامها.
- دعم إصدارات متعددة ، أحدها بالواجهة القديمة ، والآخر بالواجهة الجديدة.
- يمكن لتأجيل إصدار تغييرات "أ" حتى يتم قبول "ب" و "ج" و "د" في نفس الوقت.
لنفترض أننا اخترنا 1 ، واجهات برمجة تطبيقات متعددة. في هذه الحالة ، لدينا جزأين من الكود. قديم و جديد. مفيد جدا في بعض المواقف. نعيد الرمز القديم مرة أخرى ، ونضع علامة على أنه مهمل ، ونتفق على جدول زمني للإزالة مع فريق D. متطابق بشكل أساسي مع poly و mono.
لإصدار إصدارات متعددة ، نحتاج إلى فرع. الآن لدينا مكونان - A1 و A2. يستخدم الفريقان B و C A2 و D يستخدمان A1. نحتاج إلى أن يكون كل مكون جاهزًا للإصدار لأنه قد تكون هناك حاجة إلى تحديثات الأمان وإصلاحات الأخطاء الأخرى قبل أن يتمكن D من المضي قدمًا. في التركيب المتعدد ، يمكننا تخزين هذا في فرع طويل العمر يشعرك بالرضا. في المستودع الأحادي ، نفرض إنشاء الكود في وحدة نمطية جديدة. سيظل يتعين على الفريق D إجراء تغييرات على المكون "القديم". يمكن للجميع رؤية التكلفة التي ندفعها هنا - لدينا الآن ضعف عدد الشفرات ، وأي إصلاحات للأخطاء تنطبق على A1 و A2 يجب أن تنطبق على كليهما. مع اقتراب استخدام الفروع في التركيب المتعدد ، يتم إخفاء هذا خلف قطف الكرز. نحن نعتبر أن التكلفة أقل بسبب عدم وجود ازدواجية. من الناحية العملية ، فإن التكلفة هي نفسها: ستنشئ ، وتحرر ، وتحافظ على قاعدتين أساسيتين من الكودات المتماثلة حتى تتمكن من إزالة إحداهما. الفرق هو أن هذا الألم في المستودع الأحادي يكون مباشرًا ومرئيًا. إنه أسوأ ، وهو جيد.
أخيرًا ، وصلنا إلى النقطة الثالثة. تأخير الإصدار. من الممكن أن تؤدي التغييرات التي أجراها "أ" إلى تحسين حياة الفريق "أ". مهمة ولكنها ليست عاجلة. هل يمكننا فقط تأخير؟ في التركيب المتعدد ، ندفع هذا لتثبيت الأداة. بالطبع ، نحن نتحدث عن هذا إلى فريق D. فقط ابق على النسخة القديمة حتى تلحق بالركب! يهيئك للعب الجبان. يواصل الفريق A العمل على المكون الخاص به ، متجاهلاً حقيقة أن الفريق D يستخدم إصدارًا قديمًا بشكل متزايد (هذه مشكلة الفريق D ، فهم أغبياء). وفي الوقت نفسه ، يتحدث فريق D بشكل سيء عن موقف الفريق A المتهور تجاه استقرار الكود ، إذا تحدثوا عنه على الإطلاق. شهور تمر. أخيرًا ، قرر فريق D النظر في إمكانية الترقية ، لكن التغييرات في A أصبحت أكثر. بالكاد يتذكر الفريق "أ" متى وكيف كسروا "د". الترقية مؤلمة وستستغرق وقتًا أطول. مما يرسله إلى أسفل في حزمة الأولوية. حتى اليوم الذي لدينا فيه مشكلة أمنية في "أ" تجبرنا على التفرع. يحتاج الفريق "أ" إلى العودة بالزمن إلى الوراء ، والعثور على نقطة كان "د" فيها مستقرًا ، وإصلاح المشكلة هناك ، وجعلها جاهزة للإصدار. هذا هو الخيار الواقعي الذي يتخذه الناس ، وهو الأسوأ إلى حد بعيد. يبدو أن هذا جيد لكل من الفريق A والفريق D طالما يمكننا تجاهل بعضنا البعض.
في المستودع الأحادي ، لا يمثل الخيار الثالث حقًا خيارًا. عليك أن تتعامل مع الموقف بإحدى طريقتين. تحتاج إلى رؤية النفقات العامة لامتلاك فرعي تحرير. تعلم كيفية حماية نفسك من التحديثات التي تكسر التوافق مع الإصدارات السابقة. ولكن الأهم من ذلك: لا يمكنك تجنب محادثة صعبة.
من واقع خبرتي ، عندما تصبح الفرق كبيرة ، لم يعد من الممكن وضع النظام بأكمله في الاعتبار ، وهذا هو الجزء الأكثر أهمية. يجب تحسين رؤية الخلافات في النظام. يجب أن تعمل بنشاط لجعل الفرق ترفع أعينها عن مكوناتها وتنظر إلى عمل الفرق والمستهلكين الآخرين.
نعم ، يمكنك إنشاء أدوات ستحاول حل مشكلة التركيبات المتعددة. لكن تجربتي في تعلم التسليم المستمر والأتمتة في المؤسسات الكبيرة تخبرني بهذا: السلوك الافتراضي دون استخدام أدوات إضافية هو السلوك الذي تتوقع رؤيته. السلوك الافتراضي للمركب المتعدد هو العزلة ، وهذا هو بيت القصيد. السلوك الافتراضي للمستودع الأحادي هو المسؤولية المشتركة والشفافية ، وهذا هو بيت القصيد. في كلتا الحالتين ، سأقوم بإنشاء أداة من شأنها تخفيف الزوايا الحادة. كقائد ، سأختار مستودعًا فرديًا في كل مرة لأن الأدوات من المفترض أن تعزز الثقافة التي أريدها ، وتأتي الثقافة من القرارات الصغيرة والعمل اليومي للفريق.
يمكن للمستخدمين المسجلين فقط المشاركة في الاستطلاع. ، من فضلك.
من هم المتعصبون الكبار؟ أنصار:
-
المستودعات الأحادية
-
Rust
-
استطلاع خاطئ / كلاهما
صوّت 33 مستخدمًا. امتنع 13 مستخدما عن التصويت.
المصدر: www.habr.com