الحفاظ على الإصدارات / الفروع في إيقاع "رشيق"؟[مغلق]

Question

لدينا منتج برمجي يتطور وفقًا لإيقاع احتياجات العملاء وخريطة طريق أكثر عمومية.

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

• تنفيذ هذه الميزة في فرع تم إصداره بالفعل (ليس الهدف من وجود فرع حقًا)
• إنشاء فرع جديد - ولكن بعد ذلك يكون لدينا فرع كل ثلاثة أسابيع، ولم يعد من الممكن صيانته بعد الآن

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

هل لدى أي شخص أي تعليقات على ممارسة جيدة في ظل هذا النوع من القيود؟

Answer 1

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

• كل إصدار مخطط له (على سبيل المثال.3.0، 3.1) يحصل على رقم الإصدار الخاص به، والعلامة الخاصة به في التعليمات البرمجية المصدر.بعد إطلاقه، لا يمكنك لمسه.
• تنتقل الميزات الجديدة بعد الإصدار المخطط له إلى الإصدار المخطط التالي (على سبيل المثال.3.2)
• إذا كان يجب عليك تعديل إصدار تم إصداره من التعليمات البرمجية، فهو "إصدار غير مخطط له" ويحصل على رقم إصدار التصحيح (على سبيل المثال.3.1.1، 3.1.2).جميع التغييرات:
  • يتم تنفيذه في فرع جديد يعتمد على أحدث تصحيح لهذا الإصدار (على سبيل المثال.3.1.1 تم إنشاؤه من 3.1.0، 3.1.2 تم إنشاؤه من 3.1.1)
  • يتم دمجهم على الفور في صندوق السيارة، حتى يدخلوا أيضًا في الإصدار التالي المخطط له
• بعد تنفيذ الميزة غير المخطط لها، يمكنك تحويل الفرع إلى علامة (ويعرف أيضًا باسم لا تلمسه بعد الآن) وتعود إلى العمل في صندوق السيارة.

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

Answer 2

يوجد فرع جديد مثل ('new_feature_branch') لتجسيد أ جهد التطوير وهو غير متوافق مع الفرع الحالي (مثل "release_branch")

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

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

في الأساس، كل ذلك يعود إلى الخاص بك دمج سير العمل تعريف.

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

Answer 3

في مكتبي، نعمل عادةً من خلال 3 فروع في أي وقت محدد.

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

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

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

Answer 4

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

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

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