تخطيط النشر للتطوير القائم على الميزات

Question

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

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

تتألف بيئة DEV من SQL Server 2008 و .NET ، إطار الكيان مع SVN للتحكم في المصدر.

مصطلح ميزة هنا لا يرتبط بنموذج FDD Agile.

هل مر أي شخص بتجربة مماثلة؟

شكرا جزيلا!

Answer 1

أدير مشروعًا يشبه إلى حد كبير ما وصفته للتو.

احصل على SVN و CruiseControl.net الإعداد بأسرع ما يمكن. إنها حياة/وقت تذوق

لدي حاليًا فريقي يعمل خارج الفروع في SVN ودمج في Trunk ثم علامة عندما يكون جاهزًا للإنتاج.

حافظ على قاعدة البيانات الخاصة بك ضمن التحكم في الإصدار وربط أرقام الشرير بالعلامات (الإصدارات)

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

إصدار قاعدة البيانات الخاصة بك هو الجزء الأصعب. قبل أن نطور روتينًا صارمًا لتعديل DB كان كل شيء كابوسًا

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