ما هو مفتاح إعداد التسليم المستمر للمشاريع بنجاح؟ عمل منسق بشكل جيد لمهندسي التطوير والاختبار والبنية التحتية. شكرا يا كاب كما يقولون :) ولكن كيف نضعها موضع التنفيذ؟ في هذه المقالة سوف نشارك أفضل ممارساتنا حول كيفية تنظيم وتنفيذ كل هذا.
لقد لخصنا الأساسيات الأساسية في ورقة غش واحدة لأنفسنا ونشاركها معك:
من غير المحتمل أن يتعلم المهندسون ذوو الخبرة أي شيء جديد من المقالة ، ولكننا نأمل أن تكون هذه المعلومات مفيدة للمبتدئين.
ما هي المتطلبات وكيف تتميز
لكل مشروع عدد من المتطلبات. من المهم فهم كل منهم وعدم الخلط بينهم.
تحدد
متطلبات العمل ما يجب أن يفعله النظام من منظور الأعمال.
على سبيل المثال: يجب أن يسمح التطبيق للمستخدم ببيع التذاكر والخدمات الإضافية من أجل زيادة مبيعات الوكلاء.تصف
متطلبات المستخدم أهداف وغايات المستخدمين الذين سيعملون في النظام لتنفيذ متطلبات العمل. غالبًا ما يتم تقديم متطلبات المستخدم كحالات مستخدم.
على سبيل المثال: كمستخدم ، أحتاج إلى بيع الخدمات للأميال.المتطلبات الوظيفية - ما يجب أن يفعله النظام. تحديد وظيفة (سلوك) النظام ، والتي يجب إنشاؤها من قبل المطورين حتى يتمكن المستخدمون من تلبية متطلبات المستخدم.
متطلبات غير وظيفية - كيف يجب أن يعمل النظام. يتضمن هذا متطلبات الأداء والجودة والقيود وسهولة الاستخدام وما إلى ذلك.
أنواع المهام وترتيب وصفها في أداة تتبع المشكلات
لذا ، وصفنا أنواع المتطلبات. الآن سنقوم بتقسيمها إلى أنواع من المهام ، وفك شفرة كل نوع وإخبار كيفية وصفه بشكل صحيح.
دعونا نبدأ بأكثر ملحمة ، أي ملحمة.
تعد
Epic مهمة شائعة ، حيث يتم جمع جميع قصص المستخدم مع مراعاة وقت تطوير الخدمة. يصف الغرض الرئيسي للمنتج أو الخدمة. الهدف الرئيسي من Epic هو جمع المهام وتخزينها في مكان واحد بغض النظر عن المتطلبات الجديدة المطروحة للمنتج. تعد الملحمة دائمًا أكثر من مجرد قصة مستخدم وقد لا تتناسب مع تكرار واحد.
يسمح لك حل مشكلة Epic بإنشاء
MVP (الحد الأدنى للمنتج القابل للتطبيق) - الحد الأدنى للمنتج القابل للتطبيق. بمعنى آخر ، ما الذي يجب إصداره لتعلم وتكييف المنتج بناءً على التعليقات من المستخدمين النهائيين.
كيف تختلف الملحمة عن قصة المستخدم؟
- ملحمة ليست سوى قصة مستخدم كبيرة ، السمة المميزة لها هي وجود قيمة واضحة للمستخدم.
- بدءًا من تكوين قصص المستخدم ، أي جمع متطلبات المشروع ، ننتقل عادةً من عام إلى خاص - أولاً نحدد مفهوم المشروع ، ونختار الأشخاص الرئيسيين (مستخدمو النظام) ، وننشئ قائمة بالميزات الرئيسية ، ثم يتم تفصيل هذه الميزات في رغبات منفصلة - قصة المستخدم.
وصف Epic كما يلي:
- Title / Title Title - اسم الوظيفة الجديدة.
- الوصف / الوصف - مكتوب وفقًا للنمط:
دور المستخدم (مثل هذا المستخدم ، أنا ...) / إجراء المستخدم (أريد أن أفعل شيئًا ...) / نتيجة الإجراء (للحصول على نتيجة ...) / الفائدة أو الفائدة (ستسمح لي بالحصول على مثل هذه الفوائد ...). - خطة تنفيذ نموذجية أو وصف موجز لقصص المستخدم الرئيسية التي سيتم تنفيذها كجزء من Epic مع MVP.
- المرفقات / المرفقات - إرفاق المراسلات والتكنولوجيا والمعلومات الضرورية الأخرى.
كيفية جعل قصة المستخدم وقصة التكنولوجيا
الفرق بين قصة المستخدم وقصة التكنولوجيا هو أن Tech Story تشير إلى المتطلبات الوظيفية التي يجب أخذها في الاعتبار ووصفها في المهمة عند تطوير المنتج. وفي دور المستهلكين هنا أجزاء من النظام.
وصفها سهل. الشيء الرئيسي الذي يجب تذكره هو لماذا يتم كل هذا.
ترتيب وصف قصة المستخدم قياسي جدًا:
- العنوان / الملخص / العنوان - وصف موجز للوظيفة الجديدة أو التحسينات في لغة مفهومة للعميل.
- الوصف / الوصف يشمل الهدف الرئيسي والنتيجة المرجوة. مثل ، <دور المستخدم> ، أريد <الحصول على> بهدف <نتيجة الإجراءات>.
- معايير القبول هي قائمة بمعايير المنتج ذات الأولوية. أي تعريف قابل للقياس لما يجب القيام به مع المنتج بحيث يتم قبوله من قبل أصحاب المصلحة في المشروع.
- الملاحظات الفنية ، النماذج ، التخطيطات ، تخطيطات الصفحة.
- المرفقات / المرفقات - جميع التقنيات والوثائق والمراسلات اللازمة مع العميل.
كيفية وصف الخلل
ما المعلومات التي يجب الإشارة إليها عند الإبلاغ عن خطأ:
1. يصف
العنوان / الملخص / العنوان بإيجاز جوهر الخطأ ويشير إلى موقع المشكلة.
2. الوصف يحتوي على الخطوات التالية:
• كيفية إعادة إنتاج خطوات الخطأ / التشغيل ،
• النتيجة الحالية ،
• النتيجة المتوقعة.
3.
المرفقات / المرفقات - جميع السجلات الضرورية ولقطات الشاشة والروابط إلى Kibana والملفات الأخرى.
4.
البيئة - علامة في البيئة التي يتم فيها تكرار الخطأ ، والفئة التي تنتمي إليها المشكلة. على سبيل المثال ، خطأ في واجهة المستخدم ، خطأ CORE ، خطأ SWS ، إلخ.
5. ستسمح
الأولوية لكل عضو في الفريق بتقييم شدة المشكلة ، ويراها المدير في قائمة المرشحين الأوائل للسباق.
ولا تنس تحديد مستوى الأولوية الصحيح :)
الآن بعد أن فهمنا المبادئ العامة للعمل ، سنخبرك بكيفية تنظيم خط أنابيب النشر.
تكوين خط أنابيب النشر
لتسريع تقديم خدماتنا للإنتاج ، نقدم خط أنابيب نشر جديد ونستخدم GitFlow للعمل مع التعليمات البرمجية.
للقيام بذلك بسرعة وحيوية ، قمنا بنشر العديد من مشغلي GitLab الذين أداروا جميع مهام الدفع للمطورين. بفضل نهج GitLab Flow ، لدينا العديد من الخوادم: Develop و QA ومرشح الإصدار والإنتاج.
بدأ التكامل المستمر في جمع وتشغيل الاختبارات لكل التزام ، وتشغيل اختبارات الوحدة واختبارات التكامل ، وإضافة التحف إلى تسليم التطبيق.
يتم التطوير على هذا النحو:
- يضيف المطور وظائف جديدة في فرع منفصل (فرع الميزة). بعد ذلك ، قام بإنشاء طلب لدمج فرعه مع الفرع الرئيسي للتطوير (دمج طلب تطوير الفرع).
- ينظر مطورون آخرون في طلب الدمج ، ويقبلونه (أو لا) ويصححون التعليقات. بعد الدمج ، تتكشف بيئة خاصة في فرع صندوق الأمتعة ، حيث يتم إجراء اختبارات لرفع البيئة.
- عند اكتمال جميع هذه الخطوات ، يأخذ مهندس ضمان الجودة التغييرات إلى فرع "ضمان الجودة" الخاص به ويقوم بإجراء الاختبار.
- إذا وافق مهندس ضمان الجودة على العمل المنجز ، تنتقل التغييرات إلى فرع الإصدار المرشح ويتم نشرها في بيئة يمكن للمستخدمين الخارجيين الوصول إليها. في هذه البيئة ، يقبل العميل التقنيات ويتحقق منها. ثم نقطر كل شيء في الإنتاج.
إذا كانت هناك أخطاء في مرحلة ما ، فإننا نحلها في هذا الفرع ، وبعد ذلك ننشر النتيجة في تطوير.
لقد صنعنا أيضًا مكونًا إضافيًا صغيرًا بحيث يمكن لـ Redmine أن تخبرنا عن المرحلة التي تكون فيها الميزة. يساعد ذلك المختبرين على التقييم في أي مرحلة تحتاج إلى الاتصال بالمهمة والمطورين لتصحيح الأخطاء. لذلك يرون في أي مرحلة حدث الفشل ، يمكنهم الذهاب إلى فرع معين وتشغيله هناك.
نأمل أن تجدها مفيدة.