نموذج تفريع TFS لدعم دورة ضمان الجودة الطويلة (اختبار النظام).

Question

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

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

كيف يمكنك إعداد نموذج التفريع TFS الخاص بك.

Answer 1

يبدو أنك المرشح المثالي للاستراتيجية "القياسية" من فرع TFS/إرشادات الدمج: http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785

في جوهر الأمر، يأخذ هذا نموذج إصدار Dev <-> الرئيسي <-> الأساسي الخاص بك، ثم يضيف طبقة أخرى من المراوغة.تحصل الإصلاحات العاجلة على فرع خاص بها في جانب الإصدار من التسلسل الهرمي، بحيث لا يؤدي تطويرها + اختبارها إلى تعطيل دورة ضمان الجودة العادية التي تحدث في Main ولا تلويث قدسية الإصدار.يمكنك رؤية رسم توضيحي مرئي في الصفحة 7 من ملف PDF.

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

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

للحصول على نظرة نظرية أطول على استراتيجيات تطوير الفريق وتنفيذها في TFS، راجع الأوراق من مجموعة الأنماط والممارسات:http://msdn.microsoft.com/en-us/library/bb668991.aspx http://branchingguidance.codeplex.com/Wiki/View.aspx?title=html