المكونات المشتركة من قبل فرق مختلفة. تقرير ياندكس

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



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





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



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



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



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

في الوقت نفسه ، بقدر ما لدينا من القوة الكافية ، نحاول جعله رتيبًا وموحدًا للمستخدمين.



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

ما الذي يستحق ، تبديل مثل هذا على الشرائح ، للتأكد من عدم حدوث أي شيء على البكسل؟ نحن نحاول منع هذا من الحدوث.



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

يعجب Sergey Berezhnoy ، قائدتي ، هذه القصة كثيرًا ، حيث أننا منذ أن جمعنا الكثير في الشركة ، أريد أن يتفاعل تفاعلنا معًا في JavaScript: واحد زائد واحد هو أكثر من اثنين.



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



إذا نظرت إلى أبعد من ذلك ، إليك إصدار المستندات المعتاد. ولكن هنا ، أيضًا ، يوجد بالضبط نفس المقتطف.



أو ، دعنا نقول ، أن هناك خدمة Yandex.Air منفصلة ، والتي تتكون أقل بقليل من القصاصات المماثلة تمامًا.



أو دعنا نقول ، مقتطف الفيديو في المخطر الموجود على صفحات مختلفة من المدخل.



أو هنا مقتطف فيديو عند إضافته إلى "المفضلة" ، ثم مشاهدته في مجموعاتك.



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

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

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



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

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

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



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



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

ثم توصلنا إلى منهجية كاملة لتكون قادراً على دعم الواجهات الشائعة.



استحوذت المكتبة نفسها داخل الشركة على موقع الويب الخاص بها مع البحث وأي تصنيف.



مستودع الآن يبدو مثل هذا. ترى ، أيضا ما يقرب من 10 آلاف يرتكب وأكثر من 100 مساهم.



ولكن هذا هو مجلد المنزل ب في التناسخ الجديد. الآن تبدو مثل هذا. يوجد بالفعل أكثر من مجلداتك الخاصة داخل أكثر من نصف الشاشة.



وهكذا يبدو الموقع اليوم.



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



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

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

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

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



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



الآن هناك العديد منهم. من المثير للدهشة أن المهام هناك هي نفسها تمامًا: تسريع عملية التطوير ، وحل مشكلة الاتساق ، وعدم إعادة اختراع العجلة وعدم تكرار العمل المنجز.



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

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

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



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

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

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

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

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



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

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



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

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

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

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



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

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

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

- , CDN, . . , , , , . , , , changelog - .

, , , , . , , .

, . . , , : , ? . , . . , .