النسخة الروسية

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

أود أن أشارك قصتي كيف تعاملنا معها.

دليل على المفهوم

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

make dist for i in abc ; do scp ./result.tar.gz $i:~/ ssh $i "tar -zxvf result.tar.gz" ssh $i "make -C ~/resutl install" done 

تم تبسيط النص فقط لإظهار الفكرة الرئيسية: لم يكن هناك CI / CD. كان تدفقنا:

1. بنيت على المضيف المطور.
2. تم نشره لاختبار بيئة العرض التوضيحي.

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

فقط افعلها

استخدمنا TeamCity لمشاريعنا ولم يكن gitlab شائعًا ، لذلك قررنا استخدام TeamCity. أنشأنا يدويا VM. كنا نجري اختبارات داخل VM.

كانت هناك بعض الخطوات في تدفق البناء:

1. تثبيت بعض الأدوات المساعدة داخل بيئة أعدت يدويا.
2. تأكد من أنه يعمل.
3. إذا كان كل شيء على مايرام ، فقم بنشر RPMs.
4. تحديث التدريج إلى الإصدار الجديد.

 make install && ./libs/run_all_tests.sh make dist make srpm rpmbuild -ba SPECS/xxx-base.spec make publish 

تلقينا نتيجة مؤقتة:

1. كان هناك شيء رنابل في الفرع الرئيسي.
2. عملت في مكان ما.
3. يمكننا اكتشاف بعض القضايا العرضية.

هل تشعر بالرائحة؟

1. كان هناك جحيم التبعية مع RPMs.
2. كل شخص لديه بيئة تطوير الحيوانات الأليفة الخاصة به.
3. كانت الاختبارات تجري داخل بيئة مجهولة.
4. كان هناك ثلاثة كيانات غير محدودة تمامًا: نظام التشغيل ، توفير التركيبات والاختبارات.

تقليل السحر القذر

قمنا بتغيير التدفقات والعملية:

1. لقد أنشأنا حزمة التعريف RPM وإزالة الجحيم التبعية.
2. أنشأنا قالب تطوير VM عبر متشرد.
3. انتقلنا البرامج النصية باش إلى ansible.
4. من ناحية ، أنشأنا إطار اختبارات التكامل ، ولكن من ناحية أخرى ، استخدمنا serverspec .

نتيجة للمرحلة الحالية التي تلقيناها:

1. كانت جميع بيئة التطوير لدينا متطابقة.
2. تمت مزامنة رمز التطبيق ومنطق الحكم مع كل مرة.
3. قمنا بتسريع عملية تطوير المطورين الجدد.

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

تحسينه

لقد حللنا الكثير من القضايا المختلفة:

1. عملت اختبارات التكامل أبطأ وأبطأ لأن قالب dev VM كان أقدم من RPMs الفعلية. لقد قمنا بإعادة إنشاء القالب يدويًا ، ثم قررنا تشغيله تلقائيًا:
   
   • إنشاء VMDK تلقائيا.
   • نعلق VMDK إلى VM.
   • حزمة VM وتحميل إلى s3.
2. في حالة الدمج ، لم يكن من الممكن الحصول على حالة الإنشاء ، ونتيجة لذلك ، انتقلنا إلى gitlab.
3. اعتدنا على القيام بالإصدار اليدوي كل أسبوع ، وقمنا بالتشغيل الآلي له.
   
   • نسخة زيادة السيارات.
   • توليد ملاحظات الإصدار على أساس القضايا المغلقة.
   • تحديث سجل التغيير.
   • إنشاء طلبات دمج.
   • خلق معلما جديدا.
4. لقد نقلنا بعض الخطوات إلى عامل ميناء (الوبر ، إجراء بعض الاختبارات ، إرسال الرسائل ، إنشاء مستندات وغيرها).

ونتيجة لذلك ، بدا مخطط المرحلة الحالي كما يلي:

1. كان هناك الكثير من RPM / DEB repos للحزم.
2. كان هناك S3 كما مستودع التحف.
3. إذا قمت بتشغيل بنية مرتين لنفس الفرع ، فستتلقى نتيجة مختلفة ، لأن تبعيات حزمة التعريف لم تكن مضغوطة.
4. كانت هناك حدود غير واضحة (خطوط حمراء اللون) عبر البنيات.

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

الخاتمة

لم تكن النتيجة مثالية ، ولكن رحلة الألف لي تبدأ بخطوة واحدة ©.

PS هو crosspost