وقف الخط أو ضخ خط الأنابيب الخاص بك ، يو

إذا كانت إصداراتك سريعة ، تلقائية وموثوقة ، فلا يجوز لك قراءة هذه المقالة.

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

في هذه المقالة ، سنقوم بوصف ممارسة الإيقاف Stop the Line التي ساعدتنا على التركيز على إصلاح مشكلات التخطيط. في ثلاثة أشهر فقط ، تمكنا من زيادة معدل النشر بنسبة 10 مرات. اليوم ، أصبح نشرنا مؤتمتًا بالكامل ، ولا يستغرق إصدار المتراصة سوى 4-5 ساعات.

وقف الخط. الممارسة التي اخترعها الفريق

أتذكر كيف توصلنا إلى Stop the Line. في الماضي بأثر رجعي ، ناقشنا الإصدارات الطويلة التي منعتنا من تحقيق أهداف العدو. اقترح أحد المطورين لدينا:

- [سيرجي] دعونا الحد من حجم الإصدار. سيساعدنا ذلك في اختبار الأخطاء وإصلاحها ونشرها بشكل أسرع.
- [ديما] هل يمكننا فرض قيود على العمل الجاري (حد WIP)؟ على سبيل المثال ، بمجرد الانتهاء من 10 مهام ، نتوقف عن التطوير.
- [المطورون] ولكن قد تكون المهام مختلفة في الحجم. هذا لن يحل مشكلة الإصدارات الكبيرة.
- [I] دعونا نقدم قيودًا بناءً على مدة الإصدار ، وليس على عدد المهام. سنتوقف عن التطوير إذا استغرق الإصدار الكثير من الوقت.

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

قدمنا ​​أيضًا "Stop the Line Board" على لوحة قلب بسيطة. على ذلك ، نكتب المهام التي إما أن تساعد في دفع الإصدار الحالي ، أو تساعد على تجنب أسباب التأخير.

بالطبع ، لا يعد قرار Stop The Line قرارًا سهلاً ، ولكن هذه الممارسة تعد خطوة مهمة نحو التسليم المستمر و DevOps الأصلي.

دعنا نطلق بسرعة: من المشكلة إلى الممارسة الموقوفة ، أوقف الخط

ألم النشرات البطيئة. لماذا هم وقتا طويلا؟ تحليل

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

يدوم سباق Sprint لمدة أسبوعين ، ويتم إصدار الإصدار لمدة ثلاثة أيام. لتكون قادرًا على إصداره قبل مراجعة Sprint يوم الجمعة ، يجب أن تبدأ الإصدار يوم الاثنين بطريقة جيدة. هذا يعني أننا نعمل على هدف الركض بنسبة 50٪ فقط من الوقت. وإذا أمكننا إطلاق سراحنا كل يوم ، فإن فترة العمل الإنتاجية سوف تنمو إلى 80-90 ٪.

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

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


التين. 2. مخطط CLD: الإصدارات الطويلة تؤدي إلى إصدارات أطول

أتمتة الانحدار باستخدام أمر ضمان الجودة

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

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

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

خطوة واحدة لإيقاف الخط. #IReleaseEveryDay Initiative

لقد أنشأنا مجتمعًا يشبه التفكير #IReleaseEveryDay وناقشنا كيفية تسريع خط أنابيب النشر. الإجراءات الأولى كانت كما يلي:

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

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

ماذا لو ...

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

عندما يكون الإصدار عالقًا ، فليس من المنطقي إنشاء ميزات جديدة ، لأنها ستستمر قريبًا. في هذا الوقت ، يحظر كتابة كود جديد ، حتى في الفروع المنفصلة. تم توضيح هذا المبدأ في مقالة Martin Fowler's Continuous Delivery: "في حالة وجود مشاكل في التصميم ، يجب على فريقك تحديد أولويات حل هذه المشكلات أعلى من العمل على ميزات جديدة."

حاشية المتعري

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

التين. 3. الوامض وقف الخط

فريق المقاومة والتخريب الصغيرة

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

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

ما لم تنجح على النحو المنشود؟

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

كانت بعض الحلول إصلاحات سريعة تخفي المشكلات بدلاً من حلها. على سبيل المثال ، تم إصلاح العديد من الاختبارات عن طريق زيادة المهلات أو إضافة retrays. ركض أحد هذه الاختبارات لمدة 21 دقيقة. بحث الاختبار عن الموظف الذي تم إنشاؤه مؤخرًا في جدول بدون فهرس. بدلاً من تصحيح منطق الطلب ، أضاف المبرمج 3 مرات إعادة المحاولة. نتيجة لذلك ، أصبح الاختبار البطيء أبطأ. عندما توصل فريق Stop The Line إلى فريق مالك يركز على مشكلات الاختبار ، تمكنوا من تسريع اختباراتنا على مدار ثلاث مرات ثلاث مرات.

كيف سلوك الفرق بعد ممارسة وقف الخط؟

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

في السابق ، لم تشارك الفرق بشكل منهجي في الديون الفنية. لدينا الآن مجموعة من التحسينات الفنية المتراكمة التي نقوم بتحليلها أثناء Stop the Line. على سبيل المثال ، أعدنا كتابة الاختبارات على .Net Core ، مما سمح لنا بتشغيلها في Docker. سمحت لنا اختبارات التشغيل في Docker باستخدام Selenium Grid لموازنة الاختبارات وتقليل وقت تنفيذها.

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

تطور طريقة إيقاف الخط

في سباق بأثر رجعي العام ، نحن نراجع التجارب. على مدار الأعوام القليلة المقبلة ، قمنا بإجراء العديد من التغييرات على قواعد Stop the Line ، على سبيل المثال:

• قناة الافراج. جميع المعلومات حول الإصدار الحالي موجودة في قناة سلاك منفصلة. تحتوي القناة على جميع الفرق التي تم تضمين تغييراتها في الإصدار. في هذه القناة ، يطلب المحرر المساعدة.
• مجلة الإصدار. الشخص المسؤول عن الإصدار يسجل تصرفاته. هذا يساعد على العثور على أسباب التأخير في الإصدار واكتشاف الأنماط.
• حكم خمس دقائق. في غضون خمس دقائق من إعلان Stop the Line ، يجتمع ممثلو الفريق حول ضوء الطوارئ.
• تراكم وقف الخط. يوجد لوحة توضيحية على الحائط مع قائمة إيقاف العمل على Stop The Line - قائمة بالمهام التي يمكن أن تؤديها الفرق أثناء توقف الخط.
• لا تأخذ في الاعتبار يوم الجمعة الأخير من العدو. من غير المقارن مقارنة إصدارين ، على سبيل المثال ، أحدهما بدأ يوم الاثنين والآخر بدأ يوم الجمعة. يمكن أن يقضي الفريق الأول يومين كاملين في دعم الإصدار ، وخلال الإصدار الثاني سيكون هناك العديد من الأحداث يوم الجمعة (Sprint Review و Team Retrospective و General Retrospective) ويوم الإثنين المقبل (التخطيط العام وتخطيط فرق العمل) ، وبالتالي فإن فريق الجمعة لديه وقت أقل الافراج عن الدعم. سيتم إيقاف إطلاق الجمعة على الأرجح أكثر من الاثنين. لذلك ، قررنا استبعاد الجمعة الأخيرة من العدو من المعادلة.
• القضاء على الديون الفنية. بعد بضعة أشهر ، قررت الفرق أن يتمكنوا خلال فترة التوقف من العمل على الديون الفنية ، وليس فقط على تسريع خط أنابيب النشر.
• صاحب وقف الخط. تطوع أحد المطورين ليصبح صاحب برنامج Stop The Line. إنه منغمس بشدة في أسباب التأخير في النشرات ويدير تراكم Stop the Line. عندما يتوقف الخط ، يمكن للمالك جذب أي فريق للعمل على عناصر تراكم Stop the Line.
• بعد الوفاة. صاحب وقف الخط يحمل الوفاة بعد كل محطة.

تكلفة الخسائر

بسبب إيقاف الخط ، لم نحقق العديد من أهداف العدو. لم يكن ممثلو الشركات سعداء جدًا بتقدمنا ​​وطرحوا الكثير من الأسئلة في Sprint Review. وفقًا لمبدأ الشفافية ، تحدثنا عن ماهية لعبة Stop the Line ، ولماذا يجب عليك الانتظار لبضع سباقات أخرى. في كل مراجعة Sprint ، أظهرنا للفرق وأصحاب المصلحة مقدار الأموال التي فقدناها بسبب Stop the Line. يتم حساب التكلفة على أنها الراتب الإجمالي لفرق التطوير خلال فترة التوقف.

• نوفمبر - 2 106 000 ص.
• ديسمبر - 503 504 ص.
• يناير - 1 767 1 صفحة.
• فبراير - 2 002 278 ص.
• مارس - 0 ص.
• أبريل - 0 ص.
• مايو - 361 138 ص.

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

النتائج

في الواقع ، تحول ممارسة Stop the Line دورة التعزيز الذاتي (الشكل 2) إلى دورتين متوازنتين (الشكل 4). يساعدنا إيقاف الخط على التركيز على تحسين خط أنابيب النشر عندما يصبح بطيئًا جدًا. في 4 سرعات فقط ، نحن:

• انخفض 12 إصدارات مستقرة
• انخفاض وقت البناء بنسبة 30 ٪
• اختبارات واجهة المستخدم و API المستقرة. الآن ينقلون جميع البيئات وحتى محليًا.
• تخلص من الاختبارات الوامضة
• بدأت تثق في اختباراتنا.

التين. 4. CLD الرسم البياني: إيقاف الوقت الافراج عن أرصدة الخط

استنتاجات من الماجستير سكروم

تعد Stop The Line مثالًا رئيسيًا على حل قوي اخترعته فرق التطوير نفسها. لا يمكن لـ Scrum Master أن يأخذ ويجرّب الفرق ممارسة جديدة رائعة. لن تنجح الممارسة إلا إذا توصلت إليها الفرق نفسها. وهذا يتطلب ظروفًا مواتية: جو من الثقة وثقافة التجريب.

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

بمرور الوقت ، يجب أن تقتل ممارسة Stop the Line نفسها. كلما توقفنا في كثير من الأحيان عن الخط ، كلما استثمرنا في خط أنابيب النشر ، كلما أصبح الإصدار أكثر استقرارًا وسرعة ، قل سبب التوقف. في النهاية ، لن يتوقف الخط أبدًا ، إلا إذا قررنا خفض العتبة ، على سبيل المثال ، من 48 إلى 24 ساعة. ولكن بفضل هذه الممارسة ، قمنا بتحسين إجراء الإصدار إلى حد كبير. اكتسبت الفرق خبرة ليس فقط في التطوير ، ولكن أيضًا في التسليم السريع للقيمة للمنتجات. هذه هي DevOps حقيقية.

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