كيف تتعامل مع التوتر بين إعادة الهيكلة والحاجة إلى الدمج؟

Question

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

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

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

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

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

كيف تتعاملين مع هذا التوتر؟

شكرًا.

Answer 1

وهذه هي مشكلة عملية حقيقية. تزداد الأمور سوءا إذا كان لديك عدة إصدارات تحتاج إلى دعم ولقد تشعبت لكل منها. والأسوأ من ذلك لا يزال إذا كان لديك فرع R & D حقيقي جدا.

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

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

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

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

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

Answer 2

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

النموذج الحالي الذي نستخدمه تأثر إلى حد كبير بمقال ممتاز (الذي قمت بتوصيله من قبل) بقلم هنريك كنيبيرج: التحكم في الإصدار لفرق Agile المتعددة.

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

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

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

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

Answer 3

أعتقد أنه يمكن التعامل مع التوتر عن طريق إضافة المكونات التالية إلى عملية التطوير الخاصة بك:

1. التكامل المستمر
2. الاختبارات الوظيفية الآلية (أفترض أنك تعتمد بالفعل على اختبارات الوحدة)
3. التسليم الآلي

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

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

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

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

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

Answer 4

وربما جيت (أو غيرها من DVCS) هي أفضل في التعامل مع يدمج إلى رمز تحديثها بفضل حقيقة أنها (حقا) إدارة التغييرات بدلا من مجرد مقارنة الملفات ... و<لأ href = "HTTP: //www.joelonsoftware كوم / المواد / 2010/03 / 17.html "يختلط =" نوفولو noreferrer "> جويل يقول :

<اقتباس فقرة>   

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

ولم يحاكم بعد، على الرغم من ...

Answer 5

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

Answer 6

وربما مشكلتنا يأتي من حقيقة أن لدينا فروع التي يجب أن يكون الى حد بعيد حياة طويلة (تصل إلى 18 شهرا)، وهناك العديد من الإصلاحات التي يتعين القيام به ضدهم.

والتأكد من أننا الفرع الوحيد من قانون مستقر للغاية من شأنها أن تساعد على الأرجح، ولكن لن يكون من السهل جدا ...: (