في 1 نوفمبر 2017 ، أصبحت قائد فريق التطوير في قسم تطوير برامج Timeweb. وفي 12 نوفمبر 2018 ، سأل رئيس القسم عن موعد إعداد مقال هبراهار ، لأن قسم التسويق قد طلب ، والمتطوعون قد انتهوا ، وخطة المحتوى تتطلب شيئًا آخر)
لذلك ، أريد أن أعرض بأثر رجعي كيف تغيرت عمليات تطوير واختبار وتسليم منتجاتنا خلال العام الماضي. حول العمليات والأدوات القديمة ، عامل الميناء ، gitlab وكيف نعمل على تطويرها.
Timeweb Hoster موجود منذ عام 2006. كل هذا الوقت ، تستثمر الشركة الكثير من الجهد لتزويد العملاء بخدمة فريدة ومريحة تميزها عن المنافسين. لدى Timeweb تطبيقاتها المحمولة الخاصة بها ، وواجهة بريد إلكتروني على شبكة الإنترنت ، ولوحات تحكم استضافة افتراضية ، و VDS ، وبرنامج تابع ، وأدوات دعمه ، وغير ذلك الكثير.
يوجد حوالي 250 مشروعًا في gitlab لدينا: هذه هي تطبيقات العملاء والأدوات الداخلية والمكتبات ومستودعات التكوين. تم تطوير ودعم العشرات منها بشكل نشط: يلتزمون خلال أسبوع العمل ، ويقومون باختبارها وجمعها وإطلاقها.
بالإضافة إلى كمية كبيرة من التعليمات البرمجية القديمة ، كل هذا يجلب معه عددًا مناسبًا من العمليات الموروثة والأدوات ذات الصلة. مثل أي إرث ، تحتاج أيضًا إلى الصيانة والتحسين وإعادة البناء واستبدالها في بعض الأحيان.
من بين كل هذه الوفرة في المشروعات ، تعد لوحات التحكم أقرب إلى العملاء المضيفين. وهو بالتحديد في مشروع "لوحة التحكم" الذي نديره غالبًا من خلال تحسينات البنية التحتية المختلفة وبذل الكثير من الجهود للحفاظ على البنية التحتية المتصلة في الشكل. نشر الخبرة المكتسبة والممارسات المحببة على المنتجات الأخرى وفرقهم.
حول التغييرات المختلفة في الأدوات والعمليات على مدار العام الماضي ، سأقول.
Vagrant → عامل إنشاء
المشكلة
في يوم العمل الأول ، حاولت رفع لوحات التحكم محليًا. في ذلك الوقت ، كان هناك خمسة تطبيقات ويب في مستودع واحد:
- بو الظاهري استضافة 3.0 ،
- PU VDS 2.0 ،
- بو مشرفي المواقع ،
- الموظفين (أداة الدعم) ،
- مبادئ توجيهية (عرض مكونات الواجهة الأمامية الموحدة).
لتشغيل ، تستخدم محليا Vagrant. أطلقت متشرد ansible. لبدء وتكوينه استغرق مساعدة من الزملاء وحوالي يوم من الوقت النظيف. اضطررت إلى تثبيت إصدار خاص من Virtual Box (كانت هناك مشاكل على المستقر الحالي) ، كان العمل من وحدة التحكم داخل الجهاز الظاهري مزعجًا للغاية: تباطأت الأوامر التافهة مثل تثبيت npm / composer بشكل ملحوظ.
كان أداء التطبيقات نفسها في الجهاز الظاهري بعيدًا عن الإمكان ، نظرًا للتكدس التكنولوجي المستخدم وقوة الجهاز. ناهيك عن أن الجهاز الظاهري هو عبارة عن جهاز افتراضي ، وبالتالي فهو يشغل جزءًا كبيرًا من موارد جهاز الكمبيوتر الخاص بك.
الحل
تمت إعادة كتابة بيئة التطوير المحلية لتعمل في حاويات الإرساء. يعد النقل بالحاويات على أساس عامل الإرساء هو الحل الأكثر شيوعًا لعزل بيئة التطبيق في جميع مراحل دورة حياته. لذلك ، لا توجد بدائل خاصة.
الاستنتاجات
من الايجابيات:
- محليًا ، أصبح التطبيق أكثر استجابة ، والحاويات تتطلب أقل من VMs ،
- يستغرق بدء مثيل جديد ، كما أثبتت الممارسة ، دقائق معدودة ويتطلب فقط عامل إرساء (- أغراض) ليس أقل من إصدارات معينة. بعد الاستنساخ ، فقط قم بما يلي:
make install-dev make run-dev
كانت هناك بعض الحلول الوسط:
- اضطررت إلى كتابة روابط shell للأوامر المثبتة (الملحن ، npm ، وما إلى ذلك). إنهم ، مثل docker-compose.yml ، ليسوا عبر منصات كاملة مقارنة بـ Vagrant. على سبيل المثال ، يتطلب التشغيل تحت Mac بذل جهود إضافية ، ومن المحتمل أن يكون من الأسهل تشغيل توزيع باستخدام عامل إرساء في الجهاز الظاهري linux. ولكن هذا هو حل وسط مقبول ، كما يستخدم الفريق توزيعات قائمة على دبيان فقط ، وهذا قيد مقبول للتطوير التجاري ،
- لدعم المضيفين الظاهريين ،
يتم إطلاق حاوية تستند إلى
github.com/jwilder/nginx-proxy محليًا. ليس هذا عكازًا ، ولكن برمجيات إضافية ، تحتاج في بعض الأحيان إلى تذكرها ، على الرغم من أنها لا تسبب مشاكل.
نعم ، كان على كل فرد في الفريق أن يدرك على الأقل ما هو عامل الميناء. على الرغم من أنه بفضل البرامج النصية shell و Makefile المذكورة ، فإن المطورين يقومون بـ 95٪ من مهامهم دون التفكير في الحاويات ، ولكن في بيئة مماثلة مضمونة.
newcp-dev → cp-stands
هذه العبارات الغريبة هي أسماء الآلات ذات منصات اختبار لوحات التحكم ، الجديدة والقديمة ، على التوالي.
المشكلة
تم استخدام وصفات Ansible بشكل حصري داخل Vagrant ، لذلك لم تتحقق الميزة الرئيسية: إصدارات الحزم في prod وعلى المدرجات تختلف عن ما عمل عليه المطورون.
عدم تطابق إصدارات حزم برامج الخادم على المدرجات القديمة مع ما كان لدى المطورين ، أدى إلى مشاكل. كان التزامن معقدًا بسبب حقيقة أن مسؤولي النظام يستخدمون نظامًا مختلفًا لإدارة التكوين ، ولا يمكن دمجه في مستودع مطوري البرامج.
الحل
بعد عملية النقل بالحاويات ، لم يكن من الصعب تمديد تكوين عامل الإرساء للاستخدام على مقاعد الاختبار. تم إنشاء جهاز جديد لنشر المدرجات على DOCKER_HOST.
الاستنتاجات
أصبح المطورون الآن واثقين من أهمية البيئات المحلية واختبارها.
TeamCity → gitlab-ci
المشاكل
تكوين المشروع في TeamCity هو عملية مضنية وشاكرة. تم تخزين تكوين CI بشكل منفصل عن الكود ، بتنسيق xml ، والذي لا ينطبق عليه الإصدار العادي ، ولمحة عامة عن التغييرات. لقد واجهنا أيضًا مشكلات تتعلق باستقرار عملية الإنشاء على وكلاء TeamCity.
الحل
نظرًا لاستخدام gitlab بالفعل كمستودع لمستودعات التخزين ، فإن البدء في استخدام CI لم يكن منطقيًا فحسب ، بل سهلًا وممتعًا أيضًا. الآن أصبح تكوين CI / CD بالكامل في المستودع.
النتيجة
على مدار العام ، انتقلت جميع المشاريع التي جمعتها TeamCity بأمان إلى gitlab-ci. لقد أتيحت لنا الفرصة لتنفيذ مجموعة متنوعة من الميزات بسرعة لأتمتة عمليات CI / CD.
ستكون لقطات خطوط الأنابيب الأكثر وضوحًا:
شكل 1. ميزة فرع: يتم تضمين جميع الاختبارات والاختبارات التلقائية المتاحة. عند الانتهاء ، يرسل تعليقًا يحتوي على رابط إلى خط الأنابيب إلى مهمة redmine. المهام اليدوية لتجميع وإطلاق منصة مع هذا الفرع.
شكل 2. تطوير بناء المقرر مع تجميد رمز (الخروج: اتفاقية روتردام): بناء تطوير في الموعد المحدد مع تجميد رمز. يحدث تجميع الصور لأعمدة لوحات التحكم الفردية بشكل متوازٍ.
شكل 3. خط أنابيب العلامة: الافراج عن واحدة من لوحات التحكم. المهمة اليدوية للافراج عن التراجع.بالإضافة إلى ذلك ، من gitlab-ci ، هناك تغيير في الحالات وتعيين شخص في عملية إعادة التأهيل في المراحل قيد التقدم → مراجعة → QA ، إشعار في Slack حول الإصدارات والتحديثات المرحلية والعودة إلى الحالة السابقة.
هذا مناسب ، لكننا لم نأخذ بعين الاعتبار نقطة منهجية واحدة. بعد تنفيذ مثل هذه الأتمتة في مشروع واحد ، اعتاد الناس على ذلك بسرعة. وإذا قمت بالتبديل إلى مشروع آخر حيث لم يكن هذا موجودًا بعد ، أو كانت العملية مختلفة ، يمكنك أن تنسى نقل المهمة وإعادة تعيينها في إعادة صياغة أو ترك تعليق مع رابط لدمج طلب (مما يجعل gitlab-ci) ، مما يجبر العارض على البحث عن المشروع المطلوب السيد نفسك. في الوقت نفسه ، لا ترغب ببساطة في نسخ أجزاء .gitlab-ci.yml ورمز shell المرافق بين المشاريع ، لأنه يتعين عليك دعم لصق النسخ.
الخلاصة: الأتمتة جيدة ، ولكن عندما تكون هي نفسها على مستوى جميع الفرق والمشاريع - حتى أفضل. سأكون ممتناً للجمهور الموقر لأفكاره حول كيفية تنظيم إعادة استخدام هذا التكوين بشكل جميل.
مدة خط الأنابيب: 80 دقيقة → 8 دقائق
تدريجيا ، بدأ CI لدينا يستغرق الكثير من الوقت غير لائق. عانى المختبرون إلى حد كبير من هذا: كل إصلاح في الرئيسية كان عليه الانتظار لمدة ساعة لإصداره. يبدو مثل هذا:
شكل 4.poleline 80 لاتس دقيقة مدة.اضطررت إلى الغوص في تحليل الأماكن البطيئة لعدة أيام والبحث عن طرق للإسراع مع الحفاظ على الوظيفة.
أطول الأماكن في العملية كانت تثبيت حزم npm. وبدون أي مشاكل ، قاموا باستبدالها بالخيوط وحفظها في عدة أماكن حتى 7 دقائق.
رفضوا التحديثات التدريج التلقائي ، ويفضل التحكم اليدوي لحالة هذا الموقف.
أضفنا أيضًا العديد من المتسابقين ونقسمنا إلى مهام متوازية تجميع صور التطبيق وجميع الاختبارات. بعد هذه التحسينات ، بدأ خط أنابيب الفرع الرئيسي مع تحديث جميع المواقف في معظم الحالات 7-8 دقائق.
Capistrano → الناشر
للنشر في الإنتاج وعلى qa-stand ، تم استخدام Capistrano (ولا يزال يتم استخدامه في وقت كتابة هذا التقرير). السيناريو الرئيسي لهذه الأداة هو: استنساخ المخزون إلى الخادم الهدف وتنفيذ جميع المهام هناك.
في السابق ، تم تشغيل النشر بواسطة أيدي مهندس ضمان الجودة باستخدام مفاتيح ssh الضرورية من Vagrant. بعد ذلك ، عندما تم التخلي عن الطاغية ، انتقل كابيسترانو إلى حاوية منفصلة. يتم الآن النشر من الحاوية مع Capistrano مع العدائين gitlab ، التي تحمل علامات خاصة ولديها المفاتيح اللازمة ، تلقائيًا عند ظهور العلامات الضرورية.
المشكلة هنا هي أن عملية البناء بأكملها:
أ) يستهلك بشكل كبير موارد الخادم القتالي (خاصة العقدة / العبث) ،
ب) لا توجد وسيلة للحفاظ على إصدارات الملحن ، npm محدثة. عقدة ، الخ
من المنطقي البناء على خادم بناء (في حالتنا إنه برنامج gitlab) ، وتحميل أدوات جاهزة على الخادم الهدف. هذا سيوفر خادم المعركة من أدوات التجميع والمسؤولية الخارجية.
نحن الآن نعتبر أداة النشر بديلاً لـ capistrano (لأننا لا نملك أي روبية ، وليس لدينا الرغبة في العمل مع DSL الخاص بها) ونخطط لنقل التجميع إلى جانب gitlab. في بعض المشاريع غير الهامة ، تمكنا بالفعل من تجربتها ونحن راضون حتى الآن: يبدو الأمر أسهل ، ولم نواجه أي قيود.
Gitflow: الصليب الأحمر فروع → العلامات
يتم التطوير في دورات أسبوعية. على مدار خمسة أيام ، يتم تطوير إصدار جديد: يقبل التطوير التحسينات والإصلاحات المخطط إصدارها الأسبوع المقبل. في ليلة الجمعة ، يحدث تجميد الرمز تلقائيًا. يوم الاثنين ، يبدأ اختبار الإصدار الجديد ، ويتم إجراء تحسينات ، وبحلول منتصف أسبوع العمل ، يحدث إصدار.
في السابق ، استخدمنا فروعًا بأسماء النموذج rc18-47 ، مما يعني أن مرشح الإصدار هو الأسبوع السابع والأربعين من عام 2018. تجميد الرمز هو الخروج من فرع الصليب الأحمر من تطوير. لكن في شهر أكتوبر من هذا العام ، تحولنا إلى العلامات. تم تعيين العلامات من قبل ، ولكن بعد الحقيقة ، بعد إصدار ودمج اتفاقية روتردام مع السيد. الآن يؤدي ظهور العلامة إلى نشر تلقائي ، والتجميد عبارة عن دمج للتطوير إلى master.
لذلك تخلصنا من الكيانات الإضافية في بوابة والمتغيرات في هذه العملية.
نحن الآن "نسحب" المشروعات المتأخرة في العملية إلى سير عمل مماثل.
الخاتمة
تعد أتمتة العمليات ، وتحسينها ، بالإضافة إلى التطوير ، مسألة ثابتة: طالما أن المنتج يتطور بنشاط ويعمل الفريق ، فستكون هناك مهام مقابلة. تظهر أفكار جديدة حول كيفية التخلص من الإجراءات الروتينية: يتم تنفيذ الميزات في gitlab-ci.
مع نمو التطبيقات ، تبدأ عمليات CI في قضاء وقت طويل بشكل غير مقبول - لقد حان الوقت للعمل على أدائها. نظرًا لأن المناهج والأدوات أصبحت قديمة - يلزمك قضاء بعض الوقت في إعادة الإصلاح وإعادة النظر فيها والتحديث.
