قال هنري فورد ذات مرة: "أفضل سيارة هي سيارة جديدة". لذلك نحن في مجموعة شركات Tinkoff نفكر في إصدارات البرامج. يؤدي القصور الذاتي في عملية تقديم الميزات والإصلاحات العاجلة عاجلاً أم آجلاً إلى ديون فنية كبيرة للعميل وغالبًا ما تنتهي بركود المشروع ككل.
ضمان وقت طويل لتسويق مؤشر مع الحفاظ على الجودة ليست مهمة سهلة. من وجهة نظري ، من المستحيل بناء القضبان على الفور والتي سيكون من الممكن تنفيذها بسرعة وسهولة التغييرات بعد عدة أشهر من البداية. عادة ما يصاحب نمو المشروع زيادة في عدد الأشخاص الذين يعملون عليه ، مما يعني أنه يخلق مصدراً محتملاً للفوضى داخل إصداراتك.
لا تستحق تجربتنا اعتبارها تعليمات للنجاح ، ولكن يبدو أن هناك عددًا من الأفكار المثيرة للاهتمام بما يكفي لأشاركها معك. لنبدأ.
نقطة الانطلاق في تاريخنا هي من الناحية الفنية على النحو التالي. يتكون النظام من عدة خدمات ، يتم تفكيك قاعدة الشفرة الخاصة بها من قِبل حوالي 30 شخصًا - العديد من الفرق التي يتم تقسيمها حسب مجالات العمل ، على سبيل المثال ، خدمة الأفراد والكيانات القانونية. سأحاول تجاهل التفاصيل الفنية والمعمارية للمشروع من أجل التركيز على عملية الإصدار نفسها.
نحن نعمل على Gitflow ، لذلك ستكون المقالة مثيرة للاهتمام بشكل أساسي لأولئك الذين اختاروا طريقة التسليم المحددة هذه.
المشاكل
المشكلة الأولى التي واجهناها تتعلق بعدم كفاية التشغيل الآلي للعمليات . يرتبط تنفيذ جميع أنشطة الإصدار في فريقنا بدور مدير الإصدار (RM).
هؤلاء بعض منهم:
- ترك الافراج عن فروع وخلق العلامات.
- دمج مع سيد وتطوير الفروع.
- بناء ونشر القطع الأثرية التي تم تضمينها في الإصدار.
- التواصل مع المتخصصين المشاركين في العملية - على سبيل المثال ، مع ضمان الجودة أو المسؤولين.
تتطلب هذه المهام الروتينية موارد أكثر وأكثر مع توسيع المشروع (في حالتنا ، زيادة في عدد الخدمات) ، وبالتالي فإن الخطوة الأولى هي أتمتة كل شيء يمكن أتمتة. نحن ندمج مع أداة CI / CD من أجل تحويل ودمج فروع الإصدار ، وإطلاق تصميمات الاختبار ونشر القطع الأثرية باستخدام الزر ؛ باستخدام أداة تتبع المهام ورسول الشركة للإبلاغ في الوقت المناسب عن المشارك المسؤول عن الخطوة التالية - على سبيل المثال ، قم بتغيير حالة المهمة وتكوين الخطاف لإرسال إخطار.
لا يزال يتعين على مدير الإصدار حل التعارضات المحتملة الناشئة عن دمج الفروع يدويًا ، ولكن الإصدارات السريعة والمتكررة يجب أن تقلل من عددها إلى لا شيء.
المشكلة التالية هي الاختبار .
أحد معايير الإنشاء بالنسبة لنا هو التنفيذ الناجح للاختبارات. من المعتاد تقسيم الاختبارات إلى نوعين على الأقل: الوحدة والتكامل.
تتيح اختبارات الوحدات إمكانية التحقق من صحة الوحدات الفردية في الكود المصدري للبرنامج ، والتي غالباً ما تكون في الممارسة العملية لاختبار طريقة أو أكثر من الطرق التي لها اتصال منطقي واضح.
تتحقق اختبارات التكامل عادة من قابلية تشغيل سلسلة كاملة من هذه الوحدات ، أي تشغيل ميزة كاملة على جانب العميل. على سبيل المثال ، إذا تم تنفيذ واجهة استراحة في مهمة ما ، فسوف نتحقق من إمكانية تشغيل التخويل وإلغاء تسلسل الطلب نفسه ، وصلاحية الحقول المرسلة ، والتكامل مع الخدمات وقواعد البيانات الأخرى ، وكذلك منطق الأعمال نفسه. للوهلة الأولى ، قد يبدو أن مثل هذه الاختبارات مكتفية ذاتيا للغاية وقادرة على تغطية جميع مجالات المشاكل المحتملة. ليست هناك حاجة لفهم كيفية عمل كل لبنة فردية ، والواجهة المسماة تغلف كل المنطق من أجل الحصول على إجابة بسيطة عن المخرجات: سواء كانت تعمل أم لا.
في الواقع ، فإنها تخلق عددًا من المشكلات المؤجلة ، وإليك بعض منها:
- تؤثر مشاركة عدد كبير من المكونات المختبرة بشكل متناسب على وقت التجميع وتنفيذ هذه الاختبارات.
- غالبًا ما يؤدي تضمين منطق الاختبار إلى صعوبة ضمان صحة نتيجة الاختبار. غالبًا ما نقوم بتخصيص اختبار النتيجة ، وفي كثير من الأحيان تتطابق النتيجة مع التوقع بسبب تأثيرات جانبية عشوائية.
- تم فقد أهمية بيانات الاختبار.
- غالبًا ما تقع عمليات الدمج مع أنظمة الجهات الخارجية ، خاصة في بيئات الاختبار. ينفي هذا الوقت الذي تقضيه في الجري ، حيث أنه ليس واضحًا دائمًا: إنه انخفاض مؤقت أو انهيار ناجم عن تغييراتنا.
بالنسبة لمعظم المشاكل قد حان بالفعل حل. لكن ، كالعادة ، لا تأتي الحلول دون قيود إضافية أو مشاكل جديدة.
اختيار الاختبارات المناسبة لك وتنفيذها بشكل صحيح هو مهمة صعبة للغاية. بالإضافة إلى ذلك ، من المهم تحقيق توازن بين جودة التغطية وسرعة البناء من أجل تحسين إصداراتك.
في حالتنا ، استقرنا على هجين. نستمر في رفع جميع المكونات اللازمة لاختبار ميزة كاملة ، في وقت واحد غسل جميع التكاملات الممكنة. لحفظ عقود واجهة برمجة التطبيقات ، نستخدم Pact ، وللتحقق من التكامل مع قاعدة البيانات - حاويات الاختبار .
نتج عن هذا النهج في كتابة الاختبارات نتيجة حل للمشكلة الثالثة - وقت طويل للاختبار اليدوي للمهمة . لقد أدى استقرار الاختبارات المختلطة إلى فكرة جذب مهندس ضمان الجودة في مرحلة تحديد مهمة تجميع حالات الاختبار - مما سيتيح لهم تخطيها في مرحلة الاختبار اليدوي. أصبح التكامل مع المنتجات المفيدة مثل TestRail و Allure نوعًا من الجسر بين المطور والاختبار . تم إنشاء عقد ، ينعكس تنفيذه خطوة بخطوة في التقرير الذي تم إنشاؤه أثناء تجميع الاختبار.
TestRail. اختبار بناء التفاصيل TestRail. حالات الاختبار التي تنفذها المطور جاذبية. تقرير اختبار بناء السيارات جاذبية. معلومات لكل اختبار قيد التشغيل وتفصيل تنفيذ خطوة بخطوة يبقى توصيل التقارير بأداة تتبع المهام الخاصة بك لتتبع المهام بشفافية. ستقلل القصة الواضحة أيضًا من الوقت الذي يستغرقه تجميع الاختبارات وتنفيذها للمهام المستقبلية ذات الصلة.
جيرة. حالات الاختبار المرفقة تلقائيًا بالمهمة بهذه الطريقة ، يوفر مهندسو ضمان الجودة وقتًا كافيًا للتركيز على اختبار الحالات الاستثنائية والتكامل مع الأنظمة الأخرى.
المشكلة الأخيرة مرتبطة بهذا. للاختبار اليدوي ، يتم دمج جميع المهام من فروع الميزات في تطوير وإطلاق عملية نشر على منصة الاختبار.
أولاً ، من خلال هذا النهج ، لا يمكنك التحدث عن الاختبار الخالص للميزة ، حيث إن التغييرات ذات الصلة للمطورين الآخرين قد تدخل حيز التطوير.
ثانياً ، عند تحرير فرع الإصدار ، قد يتضح أن ضمان الجودة لم يكن لديه الوقت لاختبار بعض المهام. هناك خيار: استرجاع التغييرات التي تأثرت بهذه المهام ، أو أبطأ الإصدار حتى نهاية الاختبار.
سيتعين عليك اتخاذ هذا الاختيار في كل وقت ، إلا إذا عزلت بيئة الاختبار الخاصة بك . من المهم عدم وجود تغييرات في المكون قيد الاختبار بخلاف تلك التي تم إجراؤها بواسطة المهمة. في حالتنا ، نحتاج إلى أن نكون قادرين على التقاط خدمة أو أكثر من الخدمات التي حصلت فروعها على تغييرات ، وإدارة التوجيه داخل المجموعة عن طريق إرسال الطلبات التي نحتاجها فقط من ضمان الجودة إلى هذه الحالات. تكون المهمة معقدة إذا كانت آليات الموازنة مستخدمة بالفعل على المجموعة ، والتي يجب أيضًا أخذها في الاعتبار.
بعد أن أدركنا هذه الفرصة ، بدأنا في إجراء اختبار يدوي مباشرة على فروع ميزات منفصلة: نشر الخدمة المطلوبة طوال فترة الاختبار ، والاندماج في البيئة العامة بمعزل عن غيرها. بدمج المهام الجاهزة فقط في فرع التطوير والتخلص من الأقفال ، بدأنا نحن أنفسنا في تحديد التغييرات التي يجب تضمينها في الإصدار وأيها لا ينبغي.
تجدر الإشارة إلى أن مثل هذا الحل من غير المرجح أن يصبح رصاصة فضية لتلك الفرق التي تقوم بإجراء تغييرات على نفس الملفات تقريبًا. في هذه الحالة ، يتناسب تخزين الميزات عكسًا مع عدد التعارضات التي تنشأ أثناء الدمج. في الممارسة العملية ، مع الإصدارات المتكررة إلى حد ما ، يحدث هذا نادرًا جدًا في فريق يضم 50 مطورًا.
بدلا من الإخراج
بإيجاز ، يمكننا تحديد الأساليب الرئيسية التي يمكن أن تساعد في تسريع الإصدارات:
- أتمتة العمليات الروتينية.
- شفافية العمليات لجميع المشاركين.
- التوازن الضروري بين السرعة والجودة في كتابة الاختبارات الآلية.
- وقت أقل للاختبار اليدوي.
- عزل البيئة للاختبار.
من المهم أن نفهم أنه عند اختيار الأساليب والمبادئ والاستراتيجيات المختلفة ، فإن الأمر يستحق دائمًا البدء من سياق مشكلتك. هناك العديد من الطرق الموثوق بها والأكثر تطوراً لتسريع تسليم البرنامج إلى العميل. أدت محاولة الاستجابة للصعوبات الناشئة حديثًا إلى الاستنتاجات المذكورة أعلاه. بالنسبة لنا ، كانت الخطوة الأولى نحو نهج أكثر جرأة لإطلاق الإصدارات .