استراتيجيات إدارة كود المصدر - التفريع، ووضع العلامات، والتشعب، وما إلى ذلك.- لتطبيقات الويب

Question

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

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

إليك كيفية القيام بذلك، ويبدو الأمر هشًا نوعًا ما (حاليًا نستخدم svn ولكننا نفكر في التبديل إلى git):

1. "فرعان" - DEV وSTAGE مع إصدار معين من STAGE تم وضع علامة TRUNK عليهما
   • يقوم المطور بفحص نسخة من TRUNK لكل تغيير ويقوم بإنشاء فرع لها
   • يعمل المطور محليًا، ويتحقق من الكود بشكل متكرر (تمامًا مثل التصويت:في وقت مبكر وغالبا)
   • عندما يشعر المطور بالارتياح ولم يكن معطلاً تمامًا، قم بدمج الفرع مع DEV ونشره في موقع التطوير.
   • كرر 3-4 حسب الضرورة حتى "ينتهي" التغيير
   • دمج فرع التغيير مع التدريج، ونشره على موقع المرحلة.قم بإجراء الاختبار النهائي المتوقع.
   • بعد فترة من الوقت، قم بوضع علامة على مراجعة معينة لـ STAGE على أنها TRUNK، وادفع الصندوق مباشرة
   • قم بدمج تغييرات TRUNK مرة أخرى إلى DEV للحفاظ على مزامنتها

الآن، بعض هذه الخطوات لها تعقيد كبير تم التلويح بها يدويًا ومن الصعب جدًا تنفيذها عمليًا (TRUNK -> DEV ينقطع دائمًا) لذا يجب أن أتخيل أن هناك طريقة أفضل.

أفكار؟

Answer 1

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

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

عموما يعني أفضل:فروع أقل، مهام أقصر، وقت أقصر للإصدار، المزيد من الاختبارات.

Answer 2

قد تكون الفكرة الواضحة هي المزيد من "إعادة التأسيس" (يتم الدمج مرة أخرى في كثير من الأحيان من البيئة "الأصلية" STAGE إلى البيئة "التابعة" "DEV" إلى فرع المطور) من أجل تقليل التأثير النهائي لـ TRUNK->DEV، والذي لن تكون هناك حاجة إليه أي أكثر من ذلك.

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

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

Answer 3

اقرا هذا: http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

Answer 4

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

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

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

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