ما هي إدارة الإصدار؟
تغطي إدارة الإصدار جميع مراحل إصدار البرامج ، من التطوير والاختبار إلى النشر. إدارة الإصدار مطلوبة في كل مرة يُطلب فيها منتجًا جديدًا ، أو حتى تغيير منتج موجود. هناك خمس خطوات أساسية لإدارة الإصدار نتخذها في هذه الحالة:
- الافراج عن التخطيط
- الافراج عن البناء
- اختبار قبول المستخدم
- إعداد الإصدار
- انشر الإصدار.
الافراج عن التخطيط
تكون مرحلة التخطيط في معظم الحالات مكثفة ، حيث يتم تنظيم الإصدار بأكمله في هذه المرحلة من البداية إلى النهاية. تساعدك خطة الإصدار القوية على البقاء على المسار الصحيح والتأكد من الالتزام بالمعايير والمتطلبات بشكل صحيح.
عند التخطيط للإصدارات ، نعتقد أن التطبيقات التي طورتها فرق متعددة تحتاج إلى نهج ثابت يجب إصداره مسبقًا. هذا هو المكان الذي يدخل فيه مفهوم "إطلاق القطار". باتباع نهج إصدار القطار ، يمكن للفرق جدولة التغييرات بناءً على الإصدارات وإرسالها إلى متجر Play.
الخطوة الأولى ، حتى قبل أن نبدأ في تنفيذ إصدار القطار ، هي تحديد الفترات الزمنية لكل مرحلة. في حالتنا ، مرحلة التطوير أسبوعين. بعد ذلك ، تحتاج إلى تحديد مقدار الوقت الذي تريد أن تقضيه في اختبار التكامل وخطوات النشر. فيما يلي مثالنا على التباعد:
- القطع: يبدأ اليوم الأول.
- الاختبار الداخلي لإصدارات ألفا / UAT: ثلاثة أيام.
- نشر مرحلي [1٪] إرسال للمراجعة.
- مدة المراجعة: 3 أيام.
- يوم واحد لدى 20٪ من المستخدمين.
- يوم واحد مع 50٪ من المستخدمين ، والنمو في نفس اليوم إلى 100٪ من المستخدمين.
بناءً على المثال أعلاه ، سيستغرق الأمر ما مجموعه 10 أيام حتى يتوفر إصدار جديد من التطبيق بشكل عام.
تتمثل الخطوة التالية نحو الإصدارات في إنشاء سير عمل يمكن لفرقنا وأصحاب المصلحة الرئيسيين الرجوع إليه طوال الإصدار.
يوضح سير العمل على الفور كيفية عمل الإصدار بأكمله والدور الذي يلعبه كل عضو في الفريق. نستخدم أداة Asana لعرض هذه التفاصيل على النحو الوارد أدناه:
- توقيت
- يقدر وقت التسليم
- المتطلبات
- الحجم الكلي للمشروع
بعد تطوير الخطة ، نقدمها إلى جميع أصحاب المصلحة (مجموعة الإصدار ، مدير المنتج والقادة رفيعي المستوى) للنظر فيها. ثم نحصل على ملاحظاتهم بشأن أي ثغرات أو مشاكل يرونها في المتطلبات أو التطبيق.
بمجرد الموافقة على الخطة والانتهاء منها ، تبدأ المتعة!
الجوانب الهامة لتخطيط الإصدار
يبدو إنشاء إصدار قطار واستخدامه أمرًا رائعًا ، ولكن الحفاظ على العملية وتشغيلها أثناء التخطيط لإصدار قطار قد يكون أمرًا صعبًا. فيما يلي بعض تفاصيل هذه العملية:
- مدير التحرير يدير وينسق الإصدار.
- نحن نقبل فقط الكود الذي تمت مراجعته واختباره.
- هناك مرحلة تنفيذ في العملية.
- نحن نراقب الإصدار الذي تم إصداره من التطبيق.
الافراج عن المبنى
بعد أن تصبح خطة الإصدار جاهزة ، يمكنك البدء في اختبار المنتج للإفراج عنه. سيكون هذا هو "اختبار مستوى المستخدم" الفعلي للمنتج بناءً على المتطلبات الموضحة في خطة الإصدار.
في يوم ووقت معينين (على سبيل المثال ، الاثنين ، الساعة 15:00) ، يتم تجميد / قص الرمز. حتى هذه النقطة ، يتوفر للفرق الوقت للبحث ، واختبار ودمج الميزات في فرع التطوير ، والذي يجب أن يكون جزءًا من إصدار القطار. في الساعة 15:00 ، سيقوم مدير التحرير بإنشاء فرع تحرير من فرع التطوير. هذه الخطوة مؤتمتة مع Jenkins.
من خلال أتمتة انتقال الفرع ، نتحقق من جميع عتبات الأداء والمعايير والأتمتة من الإصدارات السابقة إلى السوق التي تم تعيينها على الإصدار الحالي كأساس للمقارنة ، ويتم حظر إصدار القطار من أي تغييرات أخرى.
بمجرد تجميد الكود ، تبدأ دورة تطوير جديدة ، وتبدأ جميع الفرق المشاركة في سباق جديد وتستمر في التطوير. إن الشيء العظيم في إصدار القطار هو أن الجميع يعرف الإصدار القادم المخطط له ويساعد الأشخاص في التخطيط لعملهم وفقًا لذلك.
إصدار الفرع والتحكم في الإصدار
لا يتوقف تطوير المنتج عادةً عند انتهاء تطوير الإصدار ، لذا فإن أول شيء نفكر فيه هو كيفية تجميد الإنشاء قيد الاختبار والعمل في نفس الوقت على ميزات جديدة للإصدار التالي. ماذا يحدث إذا ظهر خطأ في بناء الإصدار؟ كيف تصلح الخطأ إذا كنت قد أضفت بالفعل مجموعة من الأشياء الجديدة قبل اكتشاف الخطأ؟
هذا هو المكان الذي تأتي فيه استراتيجية التفرع الذكية ، والتي لديها مفهوم التفرع. كما يوحي الاسم ، فإن الكود المتفرّع يعني ، تمامًا مثل فروع الشجرة ، أن رمز الفروع يتطابق مع نقطة معينة ثم ينقسم إلى نسختين.
يمكن أن يتطور كل فرع بشكل مستقل عن الآخر. في هذه الحالة ، تظل نسخة واحدة - فرع التحرير - مجمدة في المكان الذي انتهيت منه من التطوير. هذا ما نسميه فرع مقطوع. يمكن تغيير فرع آخر (فرع التطوير) برمز جديد وإصلاحات للأخطاء دون التأثير على فرع الإصدار على الإطلاق. إذا تم العثور على خطأ في مرشح الإصدار ، يمكن تطوير إصلاح وإضافته إلى فرع الإصدار. وبالتالي ، قد يكون البناء التالي الذي تقوم بإنشائه من فرع الإصدار مرة أخرى مطابقًا للبناء الأول ، باستثناء إصلاح خطأ واحد. بهذه الطريقة ، يمكنك تقليل مخاطر الأخطاء الجديدة في الإصدار وعزل الأخطاء عن التعليمات البرمجية الجديدة. يتم أيضًا تطبيق إصلاح على فرع التطوير للتأكد من أن الخطأ نفسه لا يصل إلى الإصدار التالي.فائدة أخرى من إصدار التفريع هو أنه بمجرد أن تنشر الكود الخاص بك بالفعل ، يكون لديك فرع "مجمّد" ، وهو نسخة طبق الأصل من قاعدة الكود المنشورة. يمكنك العودة إلى هذا الرمز في أي وقت للرجوع إليه.
اختبار قبول المستخدم
يعد اختبار قبول المستخدم هو الخطوة الأكثر أهمية لإدارة الإصدار نظرًا لكمية البيانات التي تم جمعها والإصلاحات المطلوبة لجعل البناء بالضبط ما يحتاجه ليتم إطلاقه رسميًا.
كما يوحي الاسم ، عندما يتعلق الأمر بهذا النوع من الاختبارات ، فإن الشخصية الرئيسية هي المستخدم. المستخدمون هم بالضبط الأشخاص الذين سيستخدمون التطبيق. لذلك ، من الضروري جعل المستخدمين جزءًا من استراتيجية ضمان الجودة الشاملة في عملية تطوير البرمجيات. هذا هو المكان الذي يكون فيه UAT مفيدًا. هذا النوع من الاختبارات ، مثله مثل أي نوع آخر ، يضع احتياجات المستخدم في مركز تطوير المنتج. فيما يلي بعض الأسئلة التي يحاول مثل هذا الاختبار الإجابة عليها:
- هل يمكن للمستخدمين العمل مع التطبيق؟
- هل يتصرف التطبيق بالشكل المتوقع؟
- هل التطبيق يحل مشكلة المستخدم؟
بدون UAT (اختبار قبول المستخدم) الفعال ، تقل فرص نجاح المشروع الجاري تطويره بشكل كبير. هذا هو السبب في أن العرف جزء مهم من عملية التسليم. كما ذكرنا سابقًا ، يعتبر UAT جزءًا من عملية تكرارية. عند تحديد الأخطاء ، يعود الفريق لإصلاحها. تم إصلاح الخلل في فرع التحرير ثم دمجها مرة أخرى في فرع التطوير. يجب أن يمر البناء بمرحلة UAT حتى يمكن فحصه للتنفيذ النهائي والإصدار.
نصيحة للمحترفين: قم دائمًا بتضمين الاختبار الداخلي في تخطيط UAT!
كانت إحدى طرق تسريع إصدار UAT هي استخدام مسارات الاختبار الداخلية التي توفرها Google. يساعدنا ذلك في توزيع التذاكر بسرعة على الزملاء وتسجيل ملاحظاتهم عن طريق إنشاء تذاكر JIRA تلقائيًا. يضمن الفريق أيضًا أخذ الملاحظات في الاعتبار قبل تقديم الاختبار النهائي.
التحضير والإفراج
هذه الخطوة هي وضع اللمسات الأخيرة على المنتج ، مع مراعاة كل ما تم فهمه في UAT. يتضمن إعداد الإصدار أيضًا فحص الجودة النهائي بواسطة فريق مراقبة الجودة. أثناء الفحص ، يقوم فريق ضمان الجودة بإجراء فحوصات نهائية للتأكد من أن التجميع يلبي الحد الأدنى من معايير القبول ومتطلبات العمل من خطة التحرير.
بعد اكتمال المراجعة ، ستكمل مجموعة الإصدار الإصدار لبدء النشر. قبل أن يتم نشر التجميع في بيئة حية ، يجب اعتماده من قبل الفرق المسؤولة ذات الصلة مثل فريق التصميم. يضمن UAT التحقق من صحة النتيجة قبل تمريرها إلى المرحلة التالية.
نشر الإصدار
أخيرًا ، جاء اليوم المهم عندما أتى العمل الشاق لفريقنا ثماره. حان الوقت لإطلاق منتجنا في البرية للإنتاج. بالإضافة إلى إرسال التجميع ببساطة إلى بيئة الإنتاج ، فإن مرحلة التنفيذ تحتوي أيضًا على تدريب حول كيفية العمل مع المنتج لكل من المستخدم النهائي والشركة ككل. على سبيل المثال ، يجب إخطار المستخدمين بالتغييرات في الإصدار ، وهذا هو المكان الذي لا يظهر فيه "الجديد" في مجال العرض. لدينا عملية Jenkins آلية تحتوي على الخطوات التالية:
- إنشاء التجميع النهائي [تحديد الفرع واسم الإصدار].
- وأضاف "ما الجديد" في الإصدار.
- إضافة نسبة النشر.
- تحتوي كل مرحلة على إدخال يدوي للإشارات (أحمر / أخضر) من كل أوامر [UAT ، المعيار ، الأداء ، التشغيل الآلي].
بمجرد أن تسمح الإشارات بالبناء ، يتم تحميل الإصدار تلقائيًا إلى متجر Play بنسبة نشر محددة. يتم أيضًا تنفيذ الخطوات الداخلية للالتزام بالإصدار ووضع علامات عليه ، وحفظ الإصدارات في Dropbox ، والنشر والتحديث إلى قناة Slack المناسبة من خلال نفس خط الأنابيب.
في هذه الحالة ، نبدأ بالنشر إلى 1٪. في كل مرحلة ، من الضروري متابعة المراجعة ، وكذلك أدوات مراقبة قطرات الإصدار من أجل تحديد المشاكل المحتملة.
إذا أصبح الخطأ ملحوظًا عند 1٪ ، فإن الفريق لديه فرصة للرد على المشكلة وتحديد ما إذا كان سيتم إصلاحها بسرعة. إذا كان الأمر كذلك ، فيجب ألا يصل إصدار القطار إلى خطوة النشر التالية بنسبة 5٪. بدلاً من ذلك ، تم حل المشكلة لـ 1٪ من المستخدمين. بمجرد إصلاح المشكلة والتحقق من الحل ، يمكن أن ينتقل إصدار القطار إلى مرحلة 5٪.
كما هو الحال في الإصدار البسيط من إصدار القطار ، يتولى مهندس الإصدار أو فريق التحرير فقط عملية الإصدار بعد تجميد الرمز. تواصل جميع الفرق الأخرى التطور "الطبيعي".
تحليل ما بعد الإصدار
لا ينتهي عمل إدارة الإصدار عند نشر الكود ، ويستمر حتى تصبح جاهزًا لتحرير الإصدار مرة أخرى. إذا كنت تريد أن يكون تطبيقك ناجحًا ، فهو بحاجة إلى مراجعة جيدة ، كما تحتاج إلى متابعة الإصدار في الإنتاج لإصلاح الأخطاء وتنفيذ الميزات التي يحتاجها الأشخاص وحل مشكلات المستخدم. للقيام بذلك ، نستخدم Firebase Crashlytics ، حيث نتتبع أي أعطال تتطلب إصلاحًا فوريًا.
بالإضافة إلى ذلك ، توفر مراجعات التطبيق نظرة ثاقبة لمنتجك والتي يصعب الحصول عليها باستخدام الأساليب الأخرى. يوفر كل من Google Play و App Store لمطوري التطبيقات القدرة على الرد على المراجعات ، والتي يمكن أن تكون أداة مفيدة بشكل لا يصدق لمعرفة المزيد حول مشكلات التطبيقات من المستخدمين. يمكن أن تحدد الشهادات المشكلات التي يواجهها المستخدمون مع تطبيقك والإبلاغ عن التغييرات المستقبلية.
دعونا نلخص
تشرف إدارة الإصدار على عملية ديناميكية للغاية. يمثل كل إصدار فرصة لتحسين كل شيء بدءًا من سير العمل إلى قائمة المراجعة الخاصة بنا ، حيث نكتشف مجالات للتحسين معها. فيما يلي بعض الفوائد التي حصلنا عليها:
- تعزيز إنتاجيتنا من خلال تحسين الاتصال والتنسيق.
- يتم تسليم إصداراتنا بشكل أسرع ، مما يقلل أيضًا من المخاطر. تتضمن هذه التغييرات فريقًا يمكنه تقديم إصدارات عالية الجودة بسرعة عالية على أساس منتظم.
- تدعم إدارة الإصدار أيضًا تنظيم وتحسين طريقة التطوير والتشغيل.
لقد رأينا أيضًا أن عملية إدارة الإصدار الخاصة بنا سهلت على الأشخاص في جميع المجالات - من المطورين ومالكي المنتجات إلى المديرين التنفيذيين - مراجعة الخطة عالية المستوى والحصول على لمحة سريعة عن تقدمهم والعمل المتزامن.