نموذج TFS 2010 المتفرّع لتطبيق داخلي

Question

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

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

بعد بحث طويل ، قررنا استخدام جذع رئيسي من خلاله نتفرع عن فرعين فرعيين: التطوير و الصيانة (أو الإصلاح ). كما هو موضح في الدليل ، سيحدث التطوير اليومي في فرع التطوير حيث نقوم بالتكامل العكسي (RI) في كل مرة لدينا ميزات جاهزة للإصدار التالي. قبل الإصدار مباشرة ، سيتوقف التكامل العكسي وسيتم تثبيت الرمز في الفرع الرئيسي . بعد الإصدار من الرئيسي ، سيكون هناك تكامل أمامي (FI) من الرئيسي إلى التطوير و الصيانة . < / ص>

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

الآن يبدو كل شيء على ما يرام ، على الورق على الأقل ، لذلك أود سماع آراء الآخرين حول هذا النموذج.

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

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

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

Answer 1

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

http://vsarbranchingguide.codeplex.com/

لقد نفذت خطة Standard Branching لدى عدد قليل من العملاء ولم أواجه مشكلة معها.إذا كنت تخطط لاعتماد تدفقات العمل المتزامنة (أطقم الميزات ، إلخ) ، فإن دليل التفريع لديه خطط قوية لذلك أيضًا.

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