إعادة الهيكلة وفروع التطوير المتزامنة

Question

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

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

Answer 1

سأعتبر أنه من مسؤولية مطور صيانة الفرع دمج التغيير المناسب في الحالة الحالية لصندوق الأمتعة.هناك عدة احتمالات:

1. لم يتغير الرمز الموجود في صندوق السيارة ويتم تطبيق التصحيح دون تعارض.
2. تم تغيير الكود الموجود في صندوق السيارة ويتم تطبيق التصحيح، ولكن مع الحاجة إلى الدمج اليدوي.
3. لقد تغير الرمز الموجود في صندوق السيارة بالكامل ولا يمكن تطبيق التصحيح.يجب على المطور تقييم ما إذا كان العيب نفسه موجودًا في صندوق السيارة، وتطبيق إصلاح مكافئ إذا لزم الأمر.

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

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

Answer 2

هذا في النهاية سؤال حول التواصل بين الفريق، وليس سؤالًا بسيطًا للتفرع/الدمج.

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

وبعد ذلك، عليك تنبيه الفريق بأكمله إلى هذه المشكلة.

بمجرد الانتهاء من ذلك، أعتقد أن هناك طريقين مختلفين:

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

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

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

   بمجرد إصلاح جميع المشكلات المعروفة، يمكن إصدار الإصدار الجديد وإغلاق الفروع القديمة.

Answer 3

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

والبديل الآخر هو محاولة شيء من هذا القبيل MolhadoRef (<أ href ل = "http://www.mooreds.com/wordpress/archives/000398" يختلط = "نوفولو noreferrer"> المادة بلوق عن MolhadoRef وإعادة بيع ديون على علم SCM )، إذا كان يمكنك العثور على استعداد لإنتاج نظام يعادل التي تلبي احتياجاتك. وهذا هو، من الناحية النظرية، ومراقبة مصدر إعادة بيع ديون على علم بها. أنا لم ينظر فيه في بعض الوقت ولكن أخيرا أذكر أنه كان لا يزال بعيدا جدا عن كونها أي شيء أكثر من ورقة بحثية وإثبات صحة المفهوم.

Answer 4

من الناحية العملية، قد يتعين عليك القيام بعمل إضافي لجعل تغييراتك الجديدة متوافقة مع الإصدارات السابقة.

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

• الخطوة 2:الإصدار الجديد قيد الإنتاج.تأكد من أن الجميع يعرف ذلك.في هذه المرحلة، لا تتم إضافة أي ميزات جديدة إلى الإصدار القديم، ويستخدم جميع المتصلين الجدد (أو المتغيرين) الإصدار الجديد.

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

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

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

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

Answer 5

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

Answer 6

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

Answer 7

وإنشاء فرع الصيانة ويكون ذلك بمثابة منطقة عازلة بين الجذع والفروع-الإصدار.

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

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

Answer 8

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

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

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

Answer 9

وأرى اثنين من طرق منفصلة لمعالجة هذه:

1.

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

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

وبعد التغييرات قد جعلوا يمكن بعد ذلك اندمجت العودة إلى الجذع. الفروع صيانة

2

وإنشاء فرع من فروع الصيانة (فرع واحد لكل منها). هذا وسوف تستخدم لدمج الجذع مع كل فرع الصيانة. (لاحظ أن استخدام الظواهر SVN أو ما يعادلها يجب أن تستخدم من أجل الحد من عدد فروع الصيانة).

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

في الواقع يصبح كل فرع الصيانة و"جذع الفرعي".

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

Answer 10

وأنا فقط يمكن أن نردد ما قاله الآخرون، مع التأكيد على الألم الحقيقي في ل$$ أن طوابير التصحيح يمكن أن تصبح.

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

Answer 11

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

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

Answer 12

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

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

Answer 13

هل يجب عليك أن يملك أن العديد من الفروع يجري العمل عليها؟

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

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

هل لديك عدد كبير جدًا من الإصدارات القديمة لأن الفجوة قبل الإصدار الرئيسي التالي كبيرة جدًا؟

هل تحاسب العملاء على عدم الترقية أكثر مقابل الصيانة، حيث أن ذلك يكلفك أكثر؟

الرد على التعليق:

لا تزال Microsoft تدعم Windows XP على الرغم من أن Vista خارج

هذا صحيح جدًا، إلا أن Microsoft لا تزال لا تدعم Windows XP SP1 على الرغم من توقف XP SP3.

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

Answer 14

وكما أشار جريج هناك عدة سيناريوهات محتملة.

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

لقد وضعت أداة تسمى Xmerge (عبر دمج) الذي هو الخطوة الأولى نحو دمج-ريفاكتور على علم بها. انها ليست حتى الآن التلقائي، ولكنه يساعد التعامل مع دمج الصعبة التي تنطوي على كود نقلها. وصفها وهنا وتتكامل بالفعل في البلاستيك SCM 2.7.

ونحن نعمل على: الكشف عن الخطوة التلقائية والقدرة أيضا "عبر دمج" تجاه الملفات جهة متعددة (قمت بنقل الرمز إلى ملف آخر، والتي هي أيضا شائعة جدا)

.