Get best of the week

كيفية تنظيم الاختبار من أجل تسريع وتثبيت إصدارات المنتج. الجزء الأول

إذا لم يتم الاتفاق على العمل الجماعي ، فستحدث تصادمات باستمرار بين المشاركين في العملية الفردية والفرق بأكملها ، وستتداخل منتجات الشركة أو الخدمات الصغيرة داخل نفس المنتج مع بعضها البعض باستخدام الموارد والبنية التحتية المشتركة. ستكون النتيجة الأعطال الدائمة والصراعات والتباطؤ. ولن يكون بالإمكان تحقيق إطلاقات سريعة ويمكن التنبؤ بها في مثل هذه الظروف.

اسمي فيكتوريا ديجكينا ، وأنا منخرط في الاختبار في قسم تطوير وصيانة منتجات البيانات الضخمة X5 Retail Group. سأخبرك كيف قمنا بتغيير عملية الاختبار في أحد فرق منتجاتنا من أجل تسريع إعداد الإصدارات بمقدار النصف تقريبًا وتخفيف فريق الضغط. الآن نحن نقدم هذا النهج للاختبار في منتجات أخرى للشركة.



تعمل إدارة البيانات الكبيرة لمجموعة X5 Retail حاليًا على تطوير 13 منتجًا ، 4 منها في قسم تحقيق الدخل ، حيث يتم توجيه المنتجات إلى السوق الخارجية ، وأي خطأ ، سواء كان عيبًا في منتج أو ميزة تم إصدارها متأخّرًا ، له تأثير اقتصادي ويؤدي إلى خسارة العملاء . في الواقع ، هذه فرق داخلية تكسب في السوق الخارجية وتلعب وفقًا لقواعد الأعمال الصغيرة داخل شركة كبيرة.

تختلف جميع منتجاتنا بشكل كبير في أهدافها ، وبالتالي تتطلب مناهج مختلفة للتطوير والاختبار ، ولكن لديهم الكثير من القواسم المشتركة: يستخدمون نفس البنية التحتية (Kubernetes ، Greenplum ، خوادم الاختبار) ، والمطورين من فرق المنتجات المختلفة في بعض الأحيان يستبدلون بعضهم البعض لفترة من الوقت الاجازات.

في مثل هذه الحالة ، يزداد دور الاتفاقيات بشكل حاد: إذا كان جزء من الفريق لا يعرف ما يفعله الآخر ، ولدى كل فريق قواعده الخاصة ، فإن المشاكل ستظهر حتمًا.

على سبيل المثال ، يستخدم منتجان نفس البنية التحتية لاختبار الحمل ، ويحتاج كلاهما بشكل عاجل إلى إجراء الاختبارات. بدون إخطار بعضهم البعض ، يقومون بذلك في نفس الوقت ، ونتيجة لذلك ، يحصلون على نتائج خاطئة ، لأن DBMS قد "وضع" ، وبسبب عدم وضوحه. لقد أرادوا توفير الوقت في المفاوضات ، ونتيجة لذلك فقدوا الكثير من الوقت دون أي نتيجة.
لا يتم استبعاد فقدان البيانات. افترض أن أحد المنتجات يشغل خادم اختبار مجاني دون تحذير أي شخص بشأنه. رسميًا ، يعتبر الجهاز مجانيًا ، لذلك يدخل منتج آخر هناك ويمسح عن غير قصد جميع بيانات الاختبار للمنتج الأول. هذه ، بالطبع ، ليست بيانات المستخدم ، ولكنها مجرد اختبار ، لكنها لا تزال حالة غير سارة تمامًا.

قد لا يكون هناك ما يكفي من العمال ببساطة إذا لم يتم التخطيط للعمل مسبقًا. على سبيل المثال ، يعمل اختبار الضغط الآن في مديرتنا بتنسيق الخدمة ، أي أننا نختار المتخصص المناسب للفرق عند الطلب. إذا جاءت عدة فرق ، دون سابق إنذار ، للمطالبة باختبار الحمل في يوم واحد ، فقد لا يكون هناك ما يكفي من المختبرين على الإطلاق.

يبدو أن أسهل طريقة للخروج في مثل هذه الحالة هي وضع قواعد موحدة للتفاعل بين جميع المنتجات. لكن المشكلة هي أن جميع المنتجات مختلفة. بعضها مخصص للمستخدمين الداخليين ، أي المتخصصين من الإدارات الأخرى للشركة ، على سبيل المثال ، خدمات التسعير أو دراسة الطلب. الجزء الآخر تم تطويره للمستخدمين الخارجيين - على سبيل المثال ، للموردين. هذه المنتجات لها منطق معماري ومعايير جودة مختلفة تمامًا.

لا تقبل المنتجات في مراحل مختلفة من الاستعداد نفس النهج: في المرحلة المبكرة عندما يختبر المنتج الأفكار ، تكون الأولوية لفهم وظائف المستخدم وغياب التهديدات لأمن الشركة. عندما يأتي المنتج إلى الدعم ، تأتي المتطلبات الأخرى أولاً: راحة المستخدم ، واستقرار الوظائف الحالية ، وسرعة الاستجابة للعيوب والامتثال الكامل لسياسة أمان الشركة.

هذان العاملان - العمل المشترك على نفس المنطقة وميزات المنتج الفريدة - يحددان المهمة لنا : وضع قواعد تسمح للفرق بعدم التدخل مع بعضها البعض ، ولكن في نفس الوقت لن تجبر المختبرين والمطورين من ناحية أو قدمولن يقللوا من تطوير المنتجات المختلفة إلى نموذج واحد ، والاختراق جميع مزايا رشيقة ونهج المنتج في مهدها.

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

لقد كتبنا بالفعل كيف يجري هذا العمل الجماعي : في المرحلة الأولية ، علينا أن ننشئ حرفيا قاموسًا واحدًا حتى لا نخلط بين المصطلحات. لكن هذه ليست سوى البداية. بعد ذلك ، يجب أن نتفق على كتلة من الفروق الدقيقة المختلفة جدًا.

سأخبرك كيف حدث هذا على سبيل المثال لأحد منتجاتنا - نظام أتمتة المشتريات لشبكة التوزيع. وتتمثل مهمتها في ضمان تشغيل جميع العمليات من اللحظة التي يحتاج فيها المتجر إلى سلع معينة حتى لحظة استلامها.

ما هي العمليات التي تغيرت في منتجاتنا


عندما وصلنا إلى المنتج ، كان من المقرر إصدار الإصدارات كل أسبوعين ، لكنها كانت متأخرة دائمًا تقريبًا لبضعة أيام ، وكان يوم الإصدار يعني دائمًا أننا سنبقى بالتأكيد في العمل وحتى آخر يوم سنقوم بتثبيت الإصدار الحالي. كان من الضروري تغيير شيء ما.

من المهم أن نلاحظ أن التغيير هو سبب مشترك. مهما كان المبادر ، المختبر ، أو المطورين أنفسهم ، لا يمكن الاستغناء عنه دون موافقة الفريق بأكمله والحلفاء الأقوياء. يجب مناقشة أي تغييرات من قبل الفريق بأكمله من أجل جمع أكبر عدد ممكن من الأفكار وعدم تفويت المخاطر المحتملة. عمل مدير التسليم ومنتج منتجاتنا وقبل قبلي بشكل منهجي لتحسين العمليات من كل من الجانب التقني وجانب المنتج. بعد أن حضرت إلى الفريق ، قمت بفحص العملية من جانب الاختبار ، وفكرنا معًا في "استراتيجية تغييرات" متفق عليها. كانت النقطة الأولى فيه تغييرًا في تخطيط الشفرة.

تخطيط الشفرة


إجراء الحساب هو أحد "آلام" تطوير الفريق الرئيسية ، وهناك مشاكل مختلفة جدًا هنا. على سبيل المثال ، لدى الفريق فرع واحد فقط مع رمز ، ولا يتوقف تصحيح الخطأ عند هذا الحد. أو هناك العديد من الفروع ، ولكن قد تظهر المهام ذات الوظائف المتداخلة في بيئة الاختبار في نفس الوقت ، ونتيجة لذلك ، لن يتمكن المختبرون من توطين العيب أو التحقق من بعض الوظائف الجديدة التي تم حظرها بواسطة عيب إحدى المهام. وحول المطورين اليائسين الذين لا يعتبرون ذلك أمرًا سيئًا لإصلاح الأشياء الصغيرة بسرعة من دون حث الآخرين ، لن أقول شيئًا بشكل عام.

لتجنب كل هذا ، كنا بحاجة إلى تحديد عدد الفروع والبيئات ، وكذلك الاتفاق على إجراء وضع الرمز على المحك.

أسهل طريقة هي تقسيم العملية إلى فرعين برمز "نظيف" و "قذر". ولكن كان علينا تلبية العديد من الشروط:

  • « », « »
  • ,
  • .

لقد أمضينا ساعتين في مناقشة مخطط عمل جديد وتوصلنا إلى ما يلي: نبدأ ثلاثة فروع ، اثنان منهم (الإصدار والماجستير) سيكونان برمز نظيف. في "الرئيسي" هو إصدار المنتج الحالي ، في "الإصدار" - الميزات الجاهزة للتطبيق. في Dev ، يتم الاختبار ، إليك المهام الجاهزة للاختبار ، ويتم التطوير محليًا. يحدث الطرح لكل فرع بالاتفاق مع المختبر. ها هو:



ماذا أعطانا هذا من حيث الاختبار:

  • تم تقليل وقت الاختبار لكل مهمة على حدة بنسبة 20٪. لم يعد من الضروري بدء الفحص مرة أخرى ، إذا تم طرح مهمة جديدة للاختبار دون سابق إنذار ، ولم تمنع المهام الجديدة فحص المهام المنجزة بالفعل ، وتم تسريع وقت تحديد العيوب.
  • بحلول اليوم المخطط لإصلاح الإصدار ، بقيت 1-2 مهمة دون تحديد بدلاً من 4 (أي أن وقت التحقق منها انخفض إلى النصف).
  • تم تقليل وقت اختبار التكامل واختبار مرشح الإصدار من 6 ساعات إلى ساعتين (مع إعادة الاختبار).
  • انخفض عدد العيوب الموجودة في مرحلة الإصدار. سابقًا ، في إصدار الإصدار الأول ، وجدنا أكثر من 10 ، ولكن الآن ليس أكثر من 4. لقد انخفض وقت إعادة الاختبار بمقدار ساعتين.
  • كانت هناك فرصة لمواصلة التطوير بالتوازي مع الاختبار.

تم تقليل إجمالي الوقت الذي قضيناه في الاختبار ، وتأخير طرحه للمنتج ، بمقدار 8 ساعات. ساعتان فقط من مناقشة مخطط جديد للعمل مع الفريق - وتمكنت من توفير يوم عمل كامل ، والذي كان يقضي كل أسبوعين. ليس سيئا؟

لكن المشاكل ظلت قائمة.

  • , .
  • - , , .
  • .
  • , .

خلاصة القول: واصلنا العمل في يوم الإصدار.

اجتمعنا مرة أخرى. تم حل جزء من المشاكل عن طريق تحسين عملية التطوير وإضافة CI:



قمنا بإعداد طرح تلقائي لجميع البيئات لمدة شهر تقريبًا ، ولكن هذا أعطى تسارعًا في غضون يومين عمل تقريبًا. استمر الفريق في هذا الأمر لفترة طويلة ، وقد شارك مدير التوزيع والمطورين أنفسهم في هذا الأمر ، لكنهم لم يتمكنوا حتى الآن من تحقيق شيئين: بحيث يكون التطبيق على جميع البيئات متجانسًا وفي نفس الوقت يتم الحفاظ على التحكم في الإصدار. إما أن الطرح التلقائي قد انتهك المبدأ الرئيسي للاختبار "في أي وقت معين ، يجب أن يعرف المختبر ما هو موجود في كل بيئة" ، أو يبطئ المطورين الذين لم يتمكنوا من إكمال تطوير المهمة بدون إذن لبدء الاختبار.

هذه معضلة صعبة. تجاهل المبدأ الأول وبدلاً من التسريع ، تحصل على انخفاض حاد في إمكانية التنبؤ بالإصدارات والمهام التي تم تفريغها بشكل خاطئ. على سبيل المثال ، إذا تم تصحيح العيب بالفعل بالاقتران مع "مهمة نظيفة" ، فعند بدء تنفيذ مهمة ثابتة ، فمن المؤكد أنه سيلتقط العيب. لذلك ، سيكون عليك إما انتظار تصحيح عيب المهمة ذات الصلة ، أو تأجيل تاريخ الإصدار ، أو إعادة إصلاح العيب الذي تم إصلاحه بالفعل.

الطرح التلقائي ليس شخصًا ، ولن توافق عليه. لذلك ، قمنا بحل المشكلة مع الأخطاء المتبقية بطريقة مختلفة - نهج خاص للتخطيط ، ثم إضافة موقف آخر.

التخطيط للتطوير والاختبار


في البداية ، عند التخطيط ، ناقشنا أنا والفريق ما إذا كانت المهمة واضحة للمطورين ، والوقت الذي ستستغرقه وما إذا كنا سنلائم السباق. قدر المختبر المدة التي سيستغرقها الاختبار.

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

الآن ننطق جميع الأخطاء المحتملة قبل البدء في التطوير. استغرق الأمر مني أن أصبح طالبًا مملًا ، يسأل في مرحلة التخطيط كل شيء وكل شيء: "ماذا سيحدث إذا سقطت خدمة الطرف الثالث؟" ، "وإذا حصلنا على صفر ، ولكن ليس صفرًا؟" ، "ماذا لو لم نحصل على جميع البيانات؟ "،" وإذا هاجم Pechenegs؟ " وما إلى ذلك ، ولكننا الآن جاهزون لكل شيء.

بدأنا نتحدث أيضًا عن كيفية تنفيذ هذه المهمة أو تلك وكيف سنختبرها. سمح هذا بتقليل المبادرة (اختراع جميع أنواع الدراجات ، على سبيل المثال) وأعطى كل عضو في الفريق فهمًا لما يفعله زملاؤه. هذا ، بالمناسبة ، سمح لنا بالتخلي عن معايير القبول (AC).

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

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

  • تنسيق إعداد وقبول المهام والعيوب: تركوا قصص المستخدم لـ "حالة الاستخدام + المهمة الفنية" المختلطة أكثر ملاءمة لنا.
  • لحظة الاختبار: تم تحديد 5 نقاط في دورة الإصدار التي يتحكم فيها المختبرون بنشاط في عملية إنشاء المنتج.
  • قواعد تفاعل اتصال "الواجهة الخلفية - الاختبار - الواجهة الأمامية": لقد طورنا مخططًا سمح لنا بفحص جميع البيانات التي يتم إرسالها بين الواجهة الأمامية والواجهة الأمامية.
  • تسريع العمل على إصلاح العيوب: القواعد المعمول بها حول كيفية تحديد أولويات مهام تصحيح الأخطاء حتى لا تشتت انتباه المطورين مرة أخرى.

سمحت لنا هذه الإجراءات بتقصير دورة الإصدار من 2.5 أسبوعًا إلى 1. قد تبدو الزيادة في السرعة صغيرة ، ولكن الإنجاز الرئيسي كان أن إصداراتنا أصبحت أكثر استقرارًا وقابلية للتنبؤ بها - لقد أتيحت لنا الفرصة لطرح الإصدارات "بناء على أمر": يمكننا التقارب في أي يوم ، قم بنشر المهام وبحلول المساء ، سيكون كل شيء جاهزًا ومصححًا.

More articles:


All Articles