اسمي Eduard Matsukov ، أنا أصنع عداد التاكسي - تطبيق لسائقي Yandex.Taxi. أنا مشترك في البنية التحتية وكل ما يتعلق بها. منذ بعض الوقت قدمت تقريراً - تحدثت عن تجربة صداقة TeamCity مع مشروعنا ومع المطورين بشكل عام. يخصص جزء منفصل من التقرير لما يتعلق به Kotlin.
- كل يوم تقريبا يأتون لي شخصيا وإلى المطورين لدينا مع الأسئلة. وأين يمكن الحصول على التجمع؟ وأين يمكن الحصول على مثل هذا الفرع؟ لماذا وقع شيء ما؟ أين المشكلة في الكود الخاص بي؟ لماذا لا يعمل شيء بشكل صحيح؟ للقيام بذلك ، لدينا الكثير من البنية التحتية المكتوبة ذاتيا في المشروع ، والإضافات ، والعديد من الاختراقات والحيل التي نستخدمها. من ناحية ، لجعل الحياة أسهل للمطور ، من ناحية أخرى ، لتنفيذ مهام تجارية محددة.
وفي مرحلة ما ، بالطبع ، نحن نستخدم CI و TeamCity كذلك. لقد شعرنا بالارتباك - علمنا TeamCity أن نكون أصدقاء مع Kotlin وجلبنا ، يمكننا القول ، CI بالكامل والتجمع بأكمله إلى مستوى جديد تمامًا.
لكن أولاً ، القليل من التاريخ - لفهم كيف توصلنا إلى هذا ولماذا هذا المستوى أسميه شريعة منفصلة. وقد وجدت TeamCity في ياندكس لسنوات عديدة. كان علينا أن نعيش في هذا الخادم المشترك ، حيث يتم استضافة الواجهة الخلفية بأكملها ، والواجهة بالكامل ، ومؤخراً ، جميع تطبيقات الهاتف المحمول. منذ حوالي عامين التقينا جميعًا. ويقوم كل مطور بإعداد كل مشروع ليس كما يريد ، ولكن بقدر ما يستطيع أو بقدر ما يفهم مدى رغبته في فهم النظام. وليس هناك شخص واحد يعرف كل شيء ويعرف كيف. قليل من الناس يرغبون في الإزعاج ، ودراسة القوالب المنفصلة ، برمجية TeamCity. لذلك ، الجميع النشر ، من هو ما الكثير.
لقد عشنا في هذا الخادم الفردي ، وفي العام الماضي تعرضنا لحادث في TeamCity. حوالي أسبوع كان التوقف الكامل. لم يتم جمع الجمعيات ، وكان الاختبار يشكو باستمرار. شخص مفتون ، جمعت محليا.
هذا يرجع إلى حقيقة أن خادم TeamCity الخاص بنا كان ، بشكل تقريبي ، حلاً عالي الركب نما فجأة ليصبح خدمة رائعة. يتم استخدامه من قبل الآلاف من المطورين على ياندكس. بالطبع ، كان هناك نوع من التسامح مع الخطأ ، لكنه رفض أيضًا. في المرة التالية التي تم فيها تحديث TeamCity بعد إعادة التشغيل ، اتضح أن العديد من محركات الأقراص الصلبة قد انهارت ببساطة ، ولم نتمكن من الارتفاع مرة أخرى. اضطررت الى الخروج.
نحن بحاجة إلى استخلاص استنتاجات من كل ما حدث. وقد توصلنا بالطبع إلى هذه الاستنتاجات: قمنا بتحليل سبب حدوثها وكيفية التأكد من عدم حدوث ذلك مرة أخرى.
بادئ ذي بدء ، من المهم أن صعدنا لفترة طويلة للغاية واستعدنا خدمتنا. بحسب الخدمة ، أعني كلاً من العملية الفنية وجزئيًا عملية الأعمال لتسليم النشرات العادية ، لتجميع طلبات التجميع. لقد فقدنا الكثير من الأعمال الفنية ، بما في ذلك تصميمات الإصدار ، وفقدنا الكثير من الوقت في طلبات التجميع ، على حقيقة أن الاختبار لا يمكن أن يؤدي وظيفته بشكل صحيح. وبالطبع ، لقد أمضينا الكثير من الوقت في استعادة المشروع من نقطة الصفر ، وإعادة تشكيل الهيكل بأكمله ، ونظام البناء بأكمله. ثم أدركنا أن الوقت قد حان لتغيير شيء ما وإعداد خادمنا الخاص.
ذهبنا إلى هذا لفترة طويلة. كي لا نقول أن حادثة واحدة فقط أدت إلى هذا الاستنتاج. بشكل عام ، قررنا أن الوقت قد حان للذهاب إلى الجبل ، للقيام بهذا الأمر برمته. بدأنا تقديم الخدمة. يتم ذلك بسرعة كبيرة: بضعة أيام وستنتهي. عندما تتكشف كل هذا بنفسك ويمكنك الدخول إلى الداخل ، يمكنك إدارة القليل من الميزات المثيرة للاهتمام. أحدهم - يتيح لك TeamCity الجديد تكوين الإصدار.
الإصدار هو بدائي للغاية ، ولكن في الوقت نفسه موثوقة جدا وجميلة وباردة. كل ما يتم تخزينه في TeamCity بخصوص مشروعك أو أي مشروع آخر يمكن تحميله بأمان إلى Git ، ويمكنك العيش عليه بسعادة. ولكن هناك بعض المشاكل.
المشكلة الأولى هي أن جميع الناس معتادون على العمل مع TeamCity بشكل حصري من خلال الواجهة ، وهذه العادة يصعب القضاء عليها. يوجد هنا اختراق صغير للحياة: يمكنك ببساطة حظر أي تغييرات من الواجهة وإجبار جميع الأشخاص على إعادة التعلم. فريقنا لديه 2000 مطور. ليست طريقة جيدة ، أليس كذلك؟
في الواقع ، فإن سلبيات تنتهي هناك. الأهم من ذلك هو أن الناس يجب أن يتعلموا من جديد. لذلك ، يجب أن يتم منحهم أرضًا من أجل التوصل إلى استنتاج شخصي حول سبب ضرورة ذلك على الإطلاق. ومن الضروري إذن أن TeamCity ، بفضل الإصدار ، لا يسمح بتطبيق التغييرات التي تخرق النظام بطريقة أو بأخرى. TeamCity نفسه يعود مرة أخرى على أحدث مراجعة مستقرة.
في TeamCity ، يمكنك بدء كل مشروع لهذا الإصدار وتهيئته بمرونة تامة.
قليلا من البرنامج التعليمي. يتم ترتيب جميع المشاريع في TeamCity في شجرة. هناك نوع من الجذر المشترك ، وعلاوة على ذلك يأتي مثل هذا الهيكل البسيط. كل مشروع هو الجزء العلوي من هذا الرسم البياني. يمكن أن يكون بمثابة مجموعة معينة من التكوينات التي تبني شيئًا ما ، وكأحد الوالدين للمشاريع الأخرى.
في Git ، يمكنك الشحن إما دفعة واحدة أو قطعة محددة. على سبيل المثال ، إذا كان الزملاء من الواجهة الخلفية للواجهة الأمامية لا يرغبون في استخدام الإصدار ، فالرجاء ، لا يمكنك الاعتماد عليهم ، وتأمين مشروعك الشخصي بكل بساطة.
يمكنك إنشاء نظام هرمي معقد إلى حد ما ، والذي جاء به فريقنا في النهاية. لدينا جذر واحد مشترك كبير وبعض الجذور الصغيرة. الخلفية ، تطوير الأجهزة المحمولة ، الواجهة الأمامية ، Yandex.Food - يعيشون جميعًا في مستودع منفصل خاص بهم. في الوقت نفسه ، يتم تخزين المعلومات حول كل هذه المشاريع في مستودع كبير مشترك - في الجذر.
بعد أن قمت في النهاية بتوصيل هذا الإصدار ، قم بتثبيته مع جميع زملائك ، ومن أين وكيف سيعيش ، والذين سيشاركون في الدعم - بعد كل هذا ، يتعين عليك اتخاذ قرار صعب.
TeamCity يدعم تنسيقين فقط من التكوينات. مع XML ، أظن أنه لن يرغب أحد في العمل ، لذلك اخترنا التنسيق الثاني. انها تسمح لك لجعل هذه التكوينات على البرنامج النصي Kotlin.
eamCity يخلق مشروع مخضرم ، وهو نوع من أي مشروع عادي. يمكنك القيام بأحد أمرين به: إما التحميل إلى مشروعك - Android أو الخلفية أو لا يهم - أو تركه كمشروع مستقل. ثم سيكون لديك مستودع مستقل مع مشروع مستقل.
ما هو زائد لهذا النهج؟ شخصيا ، أنا وأولئك الأشخاص الذين يتعاملون مع بنيتنا التحتية على الواجهة الأمامية والواجهة الأمامية قد تعرضوا للرشوة على الفور بشيء. وحتى أولئك الذين ليسوا على دراية بكوتلين ، الذين سمعوا عن ذلك لأول مرة ، ذهبوا وبدأوا يعلمونه.
هذان الخطان ينشئان المشروع بأكمله. هذه هي لهجة واجهة برمجة تطبيقات TeamCity. يغير API كل إصدار رئيسي. هناك 2018-2 ، 2018-1 ، 2017 ، إلخ. قريباً ، على أمل ، سيتم إصدار 2019.
السطر الثاني يعلن ببساطة المشروع.
هنا هو المشروع نفسه. هذا هو رمز حقيقي تماما. هذا ما يبدو عليه مستودع الجذر الخاص بنا الآن. لا شيء إضافي ، لا شيء معقد. العمل اليدوي الوحيد المطلوب هنا هو إنشاء UUID يدويًا بنفسك. يتطلب TeamCity أن كل كائن ، كل مشروع له معرف فريد خاص به. يمكنك كتابة أي شيء هناك. أنا فقط استخدام فريق uuidgen الاسم المستعار القياسية.
هنا تبدأ المغامرة في Kotlin DSL. أعتقد أن هذه لغة غير معقدة تمامًا لإتقانها. عن طريق تحميله على IDEA أو Eclipse أو أي IDE آخر ، يمكنك الحصول على جميع الوثائق والتمييز والإكمال التلقائي والنصائح. في الواقع ، الكثير منهم في عداد المفقودين في الواجهة. لذلك ، تقول تجربتي الشخصية أن العمل مع الكود أكثر ملاءمةً وبساطة وسهولة. ما زلنا المطورين.
يبدو شيء من هذا القبيل وكأنه تكوين حقيقي يعمل الآن في الوقت نفسه ، يدعم تكوينات TeamCity بأنفسهم. وهذا هو ، TeamCity يبني التكوينات الخاصة بها في بيئتها الخاصة. إذا كان كل شيء على ما يرام وكان كل شيء على ما يرام ، فهو يشحنه بهدوء في الذاكرة ويكرر التغييرات إلى PostgreSQL. الأساس متصل بالفعل بالخدمة نفسها. وهنا سيكون خطيئة عدم استخدام جميع ميزات Kotlin.
في هذه الحالة ، بخلاف XML ، يمكن وصف هذه التكوينات باستخدام تعدد الأشكال والميراث - أي ميزات للغة Kotlin مسموح بها. النقطة المهمة الوحيدة هي أن كل هذا يمكن أن يتحول في النهاية إلى الفوضى التي كانت قائمة معنا قبل تقديم إصدار التهيئة على البرنامج النصي Kotlin.
لكن الغريب أن هذه الفوضى أصبحت أقل بكثير. لأنه قبل ذلك لم يكن من الواضح تمامًا كيف أفعل ما أريد ، وكيفية تحقيق هذه الميزة أو تلك؟ من خلال التعليمات البرمجية ، في ممارستي ، من الأسهل بكثير فهم كيفية تنفيذ أي ميزة.
تبدأ المغامرات الأكثر إثارة للاهتمام هنا: كيف يمكننا تنفيذ بعض الأشياء وكيف ، من حيث المبدأ ، جعل تفاعل المشروع مع TeamCity أسهل؟
كل شخص موجود هنا بشكل أو بآخر يستعد لإصدار بيان ، يشارك في تجميعه ، في المنشور. ننشر إصداراتنا على قنوات مختلفة على Google Play.
لدينا بيتا ، هناك تجارب ، هناك مستقر. نستخدم مكونًا إضافيًا خاصًا به روبوت ينشر التعليقات مع تقرير عن إصدار الإصدار في تذكرة الإصدار. وكل هذا مع إعداد مثل هذه النافذة الجميلة. يبدو بمجرد محاولة إنشاء إصدار. لا يمكن تجنب هذه الأسئلة.
من واجهة TeamCity ، يبدو مثل هذا. لفهم ما الذي تحتاجه لقراءة كل معلمة وأين وأين وكيف ، على الفور ، تحتاج إلى التجربة. من الوثائق ، بالإضافة إلى ما هو مرئي على الشاشة ، لا يمكن جمع شيء آخر.
في الرمز ، يبدو هذا. على الأقل حتى الآن ، لمدة نصف عام ، لم يأت أحد وسأل بعد - كيف أصنع أي ميزة؟ في معظم الأحيان من رمز كل شيء واضح بشكل حدسي.
في الوقت نفسه ، تتم بعض الأشياء بكل بساطة ، ولكنها مخفية خلف عدة طبقات من الواجهة. علينا أن نمشي ونذهب جيئة وذهابا.
فيما يلي مثال على كيفية تطبيق الأمان في TeamCity. في ممارستي ، بالنسبة لمعظم الناس ، يبدو TeamCity نظامًا باردًا إلى حد ما لا يدعم التكامل ، على سبيل المثال ، مع خدمات الأمن. لذلك ، جميع الرموز ، جميع المفاتيح ، وجميع أوراق الاعتماد معنا عالقة في الغالب. لم لا؟
في الواقع ، TeamCity آمن. إنه يعرف كيفية إنشاء ملفه الخاص على خادمه ، والذي يسمى - json credential ، كما هو موضح. ويقوم بإنشاء مثل هذا المفتاح لكل رمز ، لكل بيانات اعتماد ، والتي نقوم بإنشائها خصيصًا من خلال الواجهة. يمكنك بالفعل وضعه في الكود وتأكد من أن بيانات الاعتماد هذه لن تظهر أبدًا في سجلات TeamCity أو في واجهة TeamCity. يمكن للنظام قطع هذه المفاتيح حرفيًا من كل مكان. الواجهة بأكملها ، بشكل تقريبي ، نوع من الزخارف.
حسنًا ، لقد قمنا بإعداد بعض المعلمات الخاصة بنا ، وقمنا بإعادة توجيه المعلمات المطلوبة ، على سبيل المثال ، لإنشاء الإصدار. لكن ماذا لو أردنا الذهاب أبعد من ذلك؟ وأردنا أن نذهب أبعد من ذلك. أثناء التجميع ، يتم إطلاق الكثير من الخطوات المختلفة. نحن ندير عدة مكتبات متداخلة تبني من مستودعات مختلفة تمامًا. وأردنا فقط سحب التغييرات الجديدة. كل هذا الان. لا تهتم - على سبيل المثال ، لا تجمع مكتبة مساعدة لطلبات التجمع ، لا تقم بتحميلها إلى مستودع maven ، لا تضيف إيماءات إضافية لطلب التجمع.
لقد أنشأنا مجموعة السلسلة فقط. سأُظهر إلى النهاية مدى عدم وضوح هذا الأمر من الواجهة ، برأيي الشخصي. وهناك بالفعل القاضي لنفسك.
هذا هو ما يبدو عليه تجميع السلسلة في الواجهة.
يبدو شيء مثل هذا في التعليمات البرمجية. نشير ببساطة إلى أي التكوين يعتمد وما الذي يجب عمله إذا لم تنجح أي من التكوينات أو تم إلغاؤها من قبل المستخدم من الخارج. في هذه الحالة ، لا أريد أن يبدأ التجميع على الإطلاق. لأن ما هي الفائدة منه إذا لم نجمع كل المكتبات التابعة؟
حول نفس الروح ، كل الأشياء الأخرى يجري القيام بها. ويأخذ المشروع بأكمله في TeamCity حرفيًا 500 سطر من التعليمات البرمجية.
اتضح أنه يمكنك إعادة توجيه بعض المعلمات المثيرة للاهتمام من خلال جميع التبعيات. لقد أظهرت السلاسل لسبب ما. السلاسل مريحة ، لكن من الصعب التحضير في الواجهة. و TeamCity لا يوثق هذه الميزة الهامة مثل إعادة التوجيه من خلال المعلمات. ما هذا؟ لنفترض ، في بنينا في Gradle أو في مكان آخر ، أننا نريد أن نربط بعض الحقول المحددة ، وأرسل العنوان نفسه إلى بطاقة الإصدار. ونحن نريد أن نفعل هذا مرة واحدة ، وليس لكل مجموعة متداخلة.
يحتوي TeamCity على معلمة غير واضحة وغير موثقة تمامًا - revers.dep (التبعية العكسية). يلقي كل المعلمات التي تأتي بعد العلامة النجمية في جميع البنيات المتداخلة.
في الإخراج ، نحصل على مثل هذا الهيكل البسيط. يمكنك تعقيدها وجعل التعشيش عميقًا مثل خيالك أو احتياجاتك. وللتأكد من أنه في كل هذه التبعيات ، وفي كل هذه التكوينات ، سيتم إعادة توجيه جميع المعلمات التي نتوقعها في كل خطوة من خطوات التجميع. على استعداد للرد على أسئلتك. شكرا لكم جميعا!