تنفيذ إصدار Scrum – من تحضير المحتوى إلى النشر

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

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

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

الآن تخيل أن السباق لديه أسبوعين.

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

هل توقع الإفراج بعد كل سباق لا يزال يبدو تلقائيًا؟

تحرير معالجة المحتوى

إذا كانت جميع العمليات داخل العدو مؤتمتة ، فهناك احتمال “سحب الزناد” وتثبيت أحدث إصدار من الكود في الإنتاج في نهاية كل سباق. المشكلة هي أنني لم أختبر مثل هذه الحالة المثالية لفريق سكرم.

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

لذلك كنت بعد اكتشاف أفضل سيناريو تالي للتعامل مع الإصدارات.

كان الاستنتاج هو جعل كل عدو سريع هو Release Sprint. هذا ما تعنيه.

إصدار كود منفصل للإصدار القادم

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

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

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

لذلك فقط احتفظ بمحتوى الإصدار التالي جانبًا واتركه يصل إلى حالة مستقرة وجاهزة للإصدار.

حدد وقت الإفرازات حتى تعمل بشكل متكرر

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

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

لذلك كان الهدف هو تنفيذ الإصدار بنهاية كل عدو سريع. قد يعني ذلك ما يلي:

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

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

يبدو هذا كحل وسط جيد بين الرضا عن التسليم السريع ومواكبة أنشطة سكروم دون إزعاج كبير.

تنفيذ نشر الإصدار

عند اكتمال أنشطة الاختبار وإصلاح الأخطاء واستعداد خطوط الأنابيب بنجاح ، فإن تنفيذ خط أنابيب الإنتاج وإكمال الإصدار للإنتاج يعد عملية مباشرة تمامًا.

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

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

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

إعادة دمج فرع الإصدار في فرع التطوير

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

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

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

إنشاء إصدارات منتظمة

والآن لدينا 😀 – عملية قوية للاقتراب من الإصدار. الشيء الوحيد المفقود هو الالتزام بإبقائها منتظمة. في هذه الحالة ، بعد كل ثانية عدو سريع.

من خلال إبقائها منتظمة ، فإننا في الواقع نضع الأساس لتسهيل تحقيقه ، ويرجع ذلك أساسًا إلى:

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

خاتمة

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

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

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

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