نلاحظ اليوم كيف يموت نموذج تطوير الشلال تدريجياً في جميع أنحاء العالم. إنها ليست محبوبة بسبب ثقلها ورد فعلها الضعيف للتغيير. يؤثر هذا بشكل مباشر على مدى صلة المنتج بالمنتج ويزيد من الوقت المستغرق للسوق ، مما يؤدي إلى تكاليف إضافية. يعيد المطورون البناء على قضبان رشيقة ، ونحن لسنا استثناء.
تم إنشاء منهجية رشيقة في الأصل للفرق الصغيرة التي تصنع منتجًا جاهزًا في الوضع الشامل وهي مسؤولة عن جودتها بأنفسهم. ولكن ماذا لو قمت بتطوير أنظمة مصرفية شديدة الأهمية حول أي فرق من الفرق المرنة تعمل؟ كيفية تحقيق الثقة في المنتج الذي يعطي اختبارًا طويلًا وشاملًا كما هو الحال في الشلال؟ في هذا المنشور سوف نشارك حلنا لهذه المشكلة.
يحل الجميع المشكلة بطرق مختلفة ، ولكن عادةً ما يتعلق الأمر باختبار الأتمتة. يتم تطوير الاختبارات على بذرة ، والقواعد العامة لتشكيل تراكم الفرق المجاورة هي أطر للتفاعل بين الفرق مثل SAFe. ونتيجة لذلك ، نظرًا لمزامنة التراكم ، يمكن لفرق المنتجات ذات الصلة كتابة وإجراء الاختبارات معًا ، بما في ذلك اختبارات التكامل. لدينا مثل هذه الأطر.
لكننا الآن نضع أنفسنا مكان صاحب نظام مصرفي معقد وحرج للغاية. من ، بعد كل شيء ، مسؤول عن جودة هذا المنتج بالكامل إذا كان مشاركًا بشكل مباشر في العشرات من الفرق الرشيقة المسؤولة؟ يجب أن تتأكد من عدم حدوث أي فشل في الإنتاج. إدخال اختبار إضافي؟ مرحبًا ، شلال ، وداعًا ، TTM.
لا يوجد حل مثالي. في هذه الحالة ، سيكون لدينا دائمًا تضارب بين مبادئ المنهجية وموثوقية مضمونة للنتيجة. هذا هو الحل الوسط الذي توصلنا إليه.
بوابات الجودة
إذا افترضت خصوصية منتجك أنه غير معزول تمامًا عن الآخرين ، فيجب عند نقطة الاتصال أن تلعب بقاعدة واحدة - راقب الحد الأدنى من الجودة. يجب تغطية الكود عن طريق اختبارات الوحدة ، ويجب ألا يحتوي على عيوب خطيرة في أمن المعلومات ، ويجب أن تخضع التوزيعات لاختبارات الدخان عند تسليمها. لا قصدير ، ولكن المتطلبات إلزامية للجميع. تنفيذها هو تمرير للاختبار العام.
لذا ، بشكل عام ، تبدو ممارسة
بوابة الجودة بمثابة مجموعة من عمليات الفحص الآلية المضمنة في خط أنابيب تطوير كل نظام. في الواقع ، إنه يعكس الميل إلى اختبار التحول التحول ، والذي يتم الحديث عنه الآن في كثير من الأحيان في إطار devops.
اتفقنا مع جميع الفرق على عدد من الشيكات ، وبوابات الجودة ، والتي يجب أن يجتازوها خلال مرور مراحل دورة الحياة.
الترميز
قبل إنشاء الكود ، تحتاج إلى تحليل ثابت إلزامي ، والتحقق من الكود للتأكد من توافقه مع معايير لغة برمجة معينة. وكذلك اكتمال التغطية باختبارات الوحدة. هناك أدوات مختلفة لهذا. على سبيل المثال ، نحن نحب SonarQube. بعد اجتياز بوابة الجودة هذه ، يمكن للفرق التأكد من أنها لم تنتهك عددًا من القواعد الأساسية في مرحلة مبكرة. على سبيل المثال ، تم تجنب الازدواجية الكبيرة ، مما يزيد من تعقيد التعليمات البرمجية واحتمال حدوث مشاكل.
الاختبار الثاني قبل التجميع هو فحص IS. هناك ممارسات مقبولة بشكل عام لتحديد مشاكل نظم المعلومات في الكود والأدوات التي يمكنها مسح الكود وتحديد الأماكن الخطرة. على سبيل المثال ، يمكن أن يؤدي متغير معلن بشكل غير صحيح إلى مشاكل في الإنتاج. اتفقنا هنا على عدم السماح لكل ما يمكن الكشف عنه في مرحلة كتابة الشفرة ، إلى الآفات وعمليات فحص أكثر تعقيدًا.
بناء التوزيع
عند تجميع مجموعة التوزيع ، نتحقق دائمًا من النتيجة: أن التجميع قد تم بشكل صحيح ، وأن جميع الخدمات بدأت وتعمل كما ينبغي ، وأنه يمكن تثبيت مجموعة التوزيع في البيئة المطلوبة ، وسوف تعمل. يزيل اختبار التحقق buiild هذا سوء الفهم المحتمل بين المختبر والمطور. في ممارسة الشلال ، كان من المعتاد أن ينتهي المطور من العمل ، ويسلم التوزيع إلى المختبرين ، وعندما يتم تثبيته على الحامل ، اتضح أن التجميع لم يبدأ حتى. ثم تم كسر الدورة بأكملها ، وتمدد التطوير ولم يحدث شيء جيد على الإطلاق.
تفاعل التكامل لدينا معقد للغاية. من المهم عدم كسر الموقف حيث يمكن فحص الفرق الأخرى. يمكننا القيام بذلك بسبب التوزيع الضعيف ، وسيعرف الجيران حوله من قبلنا - سنقوم ببساطة بتعطيل عملية العمل بأكملها بالنسبة لهم. بالإضافة إلى ذلك ، يمكن أن يؤدي ذلك إلى إتلاف بيانات الاختبار. كما أن إعدادهم يكلف المال ويستغرق وقتًا طويلاً. خاصة عندما يتعلق الأمر ببيانات المستخدم المجهولة.
اختبارات الدخان
عندما يتم تثبيت مجموعة التوزيع على كل منضدة اختبار ، فإنها تمر بسلسلة من اختبارات الدخان البسيطة. يتم اختبار وظيفة التوزيع في منصة اختبار النظام. علاوة على ذلك ، يتم وضع مجموعة التوزيع على منصة اختبار التكامل ، حيث يتم اختبار تفاعلات التكامل. كما أنها تجري مجموعة من اختبارات الدخان. إذا لم ينجح التوزيع فلا يمكنه الانتقال إلى المرحلة التالية.
باستخدام بوابات الجودة هذه ، نحصل على فكرة أولية عن جودة التوزيع. إذا نجحت اختبارات الدخان ، يبدأ الفريق في الاختبار. إذا لم تجتاز مجموعة التوزيع اختبارات الدخان في هذه المرحلة ، فمن المحتمل ألا تجتاز الاختبارات اليدوية. هنا نعينه فقط إذا كان التجمع جاهزًا للذهاب إلى حفلة موسيقية.
بوابات الجودة كإطار عمل
نحن نسعى جاهدين لضمان أن تصبح بوابات الجودة إطارًا كاملاً لإدارة جودة تطوير عدد كبير من المنتجات في رشيقة. إذا فشل الفريق باستمرار في اجتياز حتى بوابات الجودة الإلزامية ، فهذه إشارة على أن هناك مشاكل يجب مناقشتها وحلها. من ناحية أخرى ، إذا كان بعض الفريق قد أتقن بالفعل بوابات الجودة الأساسية ودمجها في الإجراءات الداخلية ، فيمكنه المضي قدمًا وتضمين بوابات جودة إضافية.
في المستقبل نخطط لطرح مجموعات جديدة من بوابات الجودة الإلزامية. وكذلك اختياري ، بحيث يمكن لكل فريق بمستوى كافٍ من النضج اختيار ما يحتاجه. على سبيل المثال ، إذا كنت ترغب في معرفة استقرار حزمة التوزيع في مواقع اختبار التكامل ، فسيأخذ الفريق بوابات الجودة بمفرده. إذا كنت بحاجة إلى التأكد من أن التجمع المعقد والمتعدد المكونات لا يعيق النشر ، فسيأخذه الآخرون. شخص ما لديه انحياز تجاه الأمن في المقدمة ، شخص ما نحو التحقق من اختبار الحمل ، توافر المدرجات ، الاستجابة ، شخص ما قبل التكامل أو التحقق من بعض البيانات. سيتمكن كل فريق من العثور على بوابات عالية الجودة لقضيتهم.
من المهم ملاحظة أن بوابات الجودة ليست بديلاً عن الاختبار ، ولكنها
أداة تحكم أولية . لا أحد يلغي الاختبار. المهمة الرئيسية هنا هي تقليل الأضرار التي لحقت بالفرق الأخرى من جودة المنتج الرديئة في أقرب وقت ممكن.
مثال على خط أنابيب تابع لجهة خارجية يتضمن بوابات عالية الجودةنتائج تنفيذ بوابات الجودة
بادئ ذي بدء ، قمنا بزيادة استقرار دورة الإنتاج. تحول في العمل ، يمكننا الكشف عن الأخطاء الوظيفية الحرجة على الفور. يتم قضاء وقت أقل في تكرار التجارب المختلفة ؛ يتم الكشف عن العيوب السابقة ، لذلك يكون التخلص منها أرخص.
لقد انخفض المهلة - الوقت من بداية ترميز الميزة إلى تنفيذه في الإنتاج. ازداد استقرار المرحلة الهندسية لـ TTM نظرًا لأننا قللنا وقت التوقف عن العمل في عملية تسليم مجموعة التوزيع إلى البيئة الصناعية. نحن نقضي نفس الوقت للاختبار ، ولكن ليس لدينا أي وقت تعطل بسبب انهيار المنصة ، والحاجة إلى الانتظار حتى يتم إعادة بناء التوزيع.
ازداد الوقت المتاح لبيئات الاختبار. في السابق ، كان بإمكانك وضع تجميع عليها ونسيانها لمدة أسبوع. في هذه الأثناء ، لا يمكن اختبار الفرق ذات الصلة في هذه البيئة ، لأن جهازك معيب وستعرف عنه فقط بعد أسبوع. الآن ، عندما تضع التجميع على الأرض ، تختبره بنفسك للتعرف على المشاكل الأكثر شيوعًا ، إذا لزم الأمر ، دحرج ، أنهي ، أعده مرة أخرى. وفرصة عدم إيقاف أي شخص تصبح أعلى بكثير. سيؤدي إدخال بوابات الجودة أيضًا إلى انخفاض تكلفة استعادة المدرجات وإعادة تدريب بيانات الاختبار.
رأيك
كما قلنا في البداية ، لا يمكن قطع التناقض بين مبادئ التنمية الرشيقة والمتكاملة كعقدة جوردية. يمكن للمرء أن يسعى فقط للتأكد من أنه يجلب أقل عدد ممكن من المشاكل. في حالتنا ، تساعد ممارسة بوابات الجودة ، ولكن بالطبع لا نعتبرها مثالية. كيف تحل هذه المشكلة؟ سيكون من المثير للاهتمام بالنسبة لنا مناقشة هذه القضية.
نيكولاي فوروبيوف-سارماتوف ، Sberbank-Technology ، Sberworks
بفضل ميخائيل بيشان للمساعدة في إعداد المقال!