Планирование развертывания для разработки на основе возможностей - PullRequest
0 голосов
/ 18 февраля 2010

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

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

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

Термин «особенность» здесь не относится к гибкой модели FDD.

У кого-нибудь был подобный опыт?

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

1 Ответ

1 голос
/ 18 февраля 2010

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

Получите настройки SVN и CruiseControl.NET, как только сможете. Это вкус жизни / времени

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

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

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

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

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

...