Планирование развертывания для разработки на основе функциональных возможностей

Question

Продукт разрабатывается и поставляется в виде функций, а не релизов, что означает, что по завершении работы над функцией ее переводят на промежуточный этап, а затем в производство.В разработке может быть несколько функций, которые перекрывают сроки доставки.Таким образом, в любой момент времени база данных разработчиков и система управления версиями имеют в разработке более одной функции.Когда функция будет завершена, я хотел бы перенести в промежуточный режим только код, специфичный для конкретной функции, и изменения в базе данных.Этот процесс оказывается подверженным ошибкам и отнимает много времени по следующим причинам:

• Объекты базы данных определенного объекта не являются независимыми, но зависят и переплетены с другими объектами.Таким образом, выделение объектов, специфичных для данной функции, отнимает много времени, а иногда и трудно достижимо.Есть ли какой-нибудь лучший способ сделать это?
• В коде на стороне сервера аналогичное выделение кода, специфичного для конкретной функции, столь же громоздко, как и в базе данных.С помощью .NET Entity Framework, размещенный поверх DB, и других средств оптимизации производительности, таких как предварительно сгенерированные представления, существует ли лучший способ развертывания разработки на основе функций?

Среда разработки включает SQL Server 2008, .NET, Entity Framework с SVN для управления версиями.

Термин "функция" здесь не имеет отношения к гибкой модели FDD.

Кто-нибудь проходил через подобный опыт?

Большое спасибо!

Answer 1

Я управляю проектом, который работает очень похоже на то, что вы только что описали.

Получите SVN и CruiseControl.Настройте СЕТЬ как можно скорее.Это вкус на всю жизнь

В настоящее время моя команда работает над филиалами в SVN и объединяет их в trunk, а затем помечает тегами, когда они будут готовы к производству.

Держите свою базу данных под контролем версий и связывайте номера версий с тегами (выпусками)

Я вывел свои собственные методы управления версиями БД, основанные на этом отличная статья это предполагает создание некоторых таблиц / ограничений / триггеров, которые помогут управлять версиями вашей базы данных.

Управление версиями вашей базы данных - самая сложная часть.До того, как мы разработали строгую процедуру модификации базы данных, все было кошмаром

очевидно, что здесь недостаточно места для объяснения всех деталей, но я перестал тратить целые дни на управление / объединение кода, а теперь просто проверяю автоматизированные сборки, чтобы успокоиться и иметь время внести свой вклад в проект.