Планирование развертывания для разработки на основе функциональных возможностей
-
21-09-2019 - |
Вопрос
Продукт разрабатывается и поставляется в виде функций, а не релизов, что означает, что по завершении работы над функцией ее переводят на промежуточный этап, а затем в производство.В разработке может быть несколько функций, которые перекрывают сроки доставки.Таким образом, в любой момент времени база данных разработчиков и система управления версиями имеют в разработке более одной функции.Когда функция будет завершена, я хотел бы перенести в промежуточный режим только код, специфичный для конкретной функции, и изменения в базе данных.Этот процесс оказывается подверженным ошибкам и отнимает много времени по следующим причинам:
- Объекты базы данных определенного объекта не являются независимыми, но зависят и переплетены с другими объектами.Таким образом, выделение объектов, специфичных для данной функции, отнимает много времени, а иногда и трудно достижимо.Есть ли какой-нибудь лучший способ сделать это?
- В коде на стороне сервера аналогичное выделение кода, специфичного для конкретной функции, столь же громоздко, как и в базе данных.С помощью .NET Entity Framework, размещенный поверх DB, и других средств оптимизации производительности, таких как предварительно сгенерированные представления, существует ли лучший способ развертывания разработки на основе функций?
Среда разработки включает SQL Server 2008, .NET, Entity Framework с SVN для управления версиями.
Термин "функция" здесь не имеет отношения к гибкой модели FDD.
Кто-нибудь проходил через подобный опыт?
Большое спасибо!
Решение
Я управляю проектом, который работает очень похоже на то, что вы только что описали.
Получите SVN и CruiseControl.Настройте СЕТЬ как можно скорее.Это вкус на всю жизнь
В настоящее время моя команда работает над филиалами в SVN и объединяет их в trunk, а затем помечает тегами, когда они будут готовы к производству.
Держите свою базу данных под контролем версий и связывайте номера версий с тегами (выпусками)
Я вывел свои собственные методы управления версиями БД, основанные на этом отличная статья это предполагает создание некоторых таблиц / ограничений / триггеров, которые помогут управлять версиями вашей базы данных.
Управление версиями вашей базы данных - самая сложная часть.До того, как мы разработали строгую процедуру модификации базы данных, все было кошмаром
очевидно, что здесь недостаточно места для объяснения всех деталей, но я перестал тратить целые дни на управление / объединение кода, а теперь просто проверяю автоматизированные сборки, чтобы успокоиться и иметь время внести свой вклад в проект.