В каком месте в TFS я должен поместить свой проект базы данных?

Посмотрел другие вопросы и не вижу четкого ответа на этот вопрос.

Мы - небольшая команда разработчиков, работающая над тем, что можно описать как 3 отдельных фронт-офисных "приложения" (OnlineOrders через asp web, приложение winforms TradeManagement, ASP.NET ReportingSuite).

Однако, что бы там ни было, каждое из этих приложений использует одну центральную базу данных SQL2005, пусть она называется MainDB. Все они используют одинаковую структуру таблицы "Заказы", "Пользователи", "Учетные записи" и т.д., В значительной степени 80% объектов используются каким-либо образом в каждом приложении.

В TFS я думал, что каждое из этих 3-х приложений - это отдельные проекты с отслеживанием рабочих элементов, отчетами и т.д., Которые могут нам дать. Похоже, что все работает нормально, создавая наши решения на основе кода.

Теперь я пытаюсь понять, как я могу получить базу данных MainDB в TFS Source Control. Я не вижу очевидного способа сделать это.

Вопрос заключается в следующем: должен ли я создать проект базы данных для MainDB, экспортировать схему в сценарии проекта и добавить этот проект базы данных в каждое решение, внутри каждого проекта TFS?

Или у меня должен быть отдельный проект TFS только для моего проекта базы данных? И разработчик должен будет открыть как проект TFS базы данных MainDB, так и (например) проект TFS TradeManagement, чтобы разработать новую функцию (так как большинство новых функций будет также включать некоторые изменения в БД)? Кажется, очень тяжелые руки.

Или это обычное дело просто иметь один массивный проект TFS, который называется "Все", и внутри которого есть ветки функций для проектов кода, ветвь базы данных для базы данных и любые другие проекты, которые могут использовать базу данных MainDB? (в img предположим, что сценарии MainDB находятся в папке "База данных")

и т.д. Человек, я в замешательстве. Codeplex, кажется, указывает на простоту, помещая все решения внутри одного большого решения. Это устойчиво?

Спасибо за ответы, действительно здорово.

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

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

Мне придется подумать еще немного об этом.

Горизонтальное разбиение БД - это не то, что я рассмотрел. Такое ощущение, что слишком много объектов базы данных совместно используется, чтобы иметь возможность разбивать его на горизонтальные блоки - у нас были бы одни и те же объекты (таблицы/спрэки и т.д.) В нескольких блоках, которые, я думаю, могли бы еще больше сбить нас с толку.

Ответ 1

Комментарий относительно обработки базы данных, такой как API, находится на правильном пути. Хотя реализация очень различна - для создания и развертывания базы данных из исходного кода требуются специальные инструменты, а не только компилятор + xcopy. Ваша ситуация принципиально не отличается от команд, которые используют общую библиотеку утилиты.

К счастью, это очень хорошо изученная тема. Кроме того, нет ничего особенного в TFS об этом; вы можете прочитать документацию для любой системы управления версиями с надежными функциями ветвления и слияния, которые в настоящее время являются большинством из них. Практическая Perforce, красная книга Bean (SVN), блог Эрика Синка (Vault) и т.д., Все имеют хорошие идеи. Я особенно пристрастен к Презентация Laura Wingerd по кодонам. Естественно, вы должны прочитать последнее руководство TFS.

Здесь, в StackOverflow, вопрос о внедрении этих концепций в практику также возникает несколько раз. Это лучшее общее резюме для пользователей TFS: Структура управления исходным кодом Team Foundation Server Она включает в себя важнейшие отраслевые принципы...

все ветки автономны. разрешений между ветвями или между ветвью и фиксированным (не разветвленным) местоположением
относительные пути внутри ветвей инвариантны
продвинутая модель хорошо определена и применяется в равной степени ко всем инженерным артефактам: разработка → интеграция → производство (для использования их терминов для первичных кодовых линий, многие другие широко используются, как правило, составляют одну и ту же основную идею)
1 Интеграционная ветвь (ака Trunk, aka Main), которая связывает устойчивые и неустойчивые стороны дерева. невозможно разрешить одноранговое слияние.
переменная # ветвей Dev в зависимости от степени изоляции, необходимой между командами/функциями/рефакторами.
переменная # ветвей Release в зависимости от частоты исправлений, независимо от того, перекрываются ли какие-либо релизы, и насколько строгими являются требования аудита.
Если вы захотите проверить вторичные ресурсы, такие как документация, двоичные файлы сторонних разработчиков, компиляторы и т.д., они входят в структуру ветки. см. правило № 1.

... наряду с некоторыми специфическими особенностями TFS...

не использовать сопоставления рабочего пространства, чтобы взломать общие файлы. (dunno, кто первым написал это "руководство" - к счастью, он больше не появляется в последней версии P & P)
не вставлять/объединяться в подкаталог существующей иерархии веток. (опять же, некоторые "советы", которые последовали за TFS с момента его дебюта, хотя я еще не встречал кого-то, кто был счастлив, что последовали за ним).
не используйте папку TeamBuildTypes по умолчанию; как и весь код, ваши скрипты сборки должны следовать за пунктами # 1-3 сверху

(Откровенно говоря, ответы на них слишком сложны. Даже если у вас есть десятки или сотни веток, нет необходимости встраивать их так глубоко внутри исходного дерева, как это сделал пересмотренный вопрос. глубже, чем другие, особенно запутывает, ИМО скрывает ключевые выводы от читателей, которые не знакомы с крупномасштабным управлением источниками и/или пространственным разделением в целом. Простота - это золотой, если вы надеетесь заставить всех в вашей организации следовать "правилам дорога", как выражается Уингерд.)

В любом случае, я знаю, что вы не спрашивали о разветвлении и объединении конкретно, но способ, которым вы располагаете свое исходное дерево, имеет прямые последствия для вашего общего программного процесса. Если вы не выполняете правила, подобные # 1, когда вы добавляете проект базы данных, ваши интерфейсные команды приложений никогда не смогут функционировать независимо. Таким образом, ваше первое предложение (структура, изображенная под $/FrontOfficeDevelopment) намного ближе к знаку, чем вторая. Но вам нужно идти дальше. Переместите папки для 3-х приложений + базы данных на один уровень глубже в дереве. I.e., дать им общий родительский элемент - назовите его "Интеграция", чтобы соответствовать другому примеру StackOverflow. Если вам когда-либо понадобится разветвление, вы можете сделать это в одном автономном действии, разветкив этот контейнер; было бы намного сложнее, если бы каждое приложение было папкой верхнего уровня в Team Project. Вскоре ваше исходное дерево будет выглядеть так же, как идеалы, изображенные на диаграммах "TFS Guidance II"... не случайно:)

$/Everything
   |- Integration
       |- 3rdPartyAssemblies
       |- Database
       |- OnlineOrders
            |- Code
            |- Tests*
       |- ReportingSuite
            |- Code
            |- Tests
       |- TeamBuildTypes
            |- TfsBuild.proj
            |- QuickBuild.targets
            |- FullBuild.targets
            |- FullBuildAndTest.targets
       |- TradeManagement
            |- Code
            |- Tests
   |- Development #1
       |- 3rdPartyAssemblies
       |- Database
       |- etc
   |- Release #1
       |- 3rdPartyAssemblies
       |- Database
       |- etc

* Прерывание ваших тестов для каждого приложения, как показано выше, облегчает работу отдельных команд на их куске дерева. Ребятам OnlineOrders нужно только загружать файлы OnlineOrders +, такие как 3rdParty и Database, что удобно, если ваши приложения очень большие или их десятки/сотни. Тем не менее, это равнозначно, чтобы сделать одну верхнюю панель тестов TEST внутри ветки, как показано ниже:

   |- Integration
       |- Database
       |- OnlineOrders
       |- ...
       |- Tests
            |- Database
            |- OnlineOrders
            |- ...

Это упрощает запуск всего набора тестов сразу и снижает общую глубину/сложность дерева. Недостатком является то, что вам придется чаще перемещаться по дереву в повседневной работе. Возможно, более тревожный долгосрочный подход требует, чтобы вы поддерживали параллельную структуру вручную. Добавление/удаление проектов, рефакторинг кода, ведомственные реорганизации, аутсорсинг - многое может изменить структуру основных кодовых папок с течением времени. Если Тесты не обновлены, чтобы соответствовать, вы будете смущать QA людей как минимум и достойную возможность сломать автоматизацию тестирования для загрузки.

Вы также задали вопрос о том, следует ли разделить усилия вашей компании на Team Projects. Хорошей новостью является то, что это решение полностью ортогонально к выбранному вами ветки/слиянию. В отличие от сборок, отчетов, артефактов Sharepoint и (в некоторой степени) рабочих элементов, которые тесно связаны с понятием Team Projects, система управления исходными текстами TFS - это просто одно большое дерево, которое охватывает все их. Мне пришлось использовать проект "Все" на моей диаграмме, потому что его было легче рисовать - и потому, что я, по общему признанию, частично относился к этой стратегии, но на самом деле это не имеет значения.

Тем не менее, спаривание того, что мы узнали до сих пор в концепции TFS "Team Project", требует дополнительной мысли. Я признаю, что это не очевидно из беглого взгляда на продукт, что, черт возьми, "Team Project" делает в первую очередь. Достаточно сказать, что они предназначены для действительно больших контейнеров. Возьмем некоторые знакомые примеры. Windows и Office обязательно должны быть отдельными командами - они разрабатываются в независимых графиках выпуска, используя очень разные инженерные практики, выполняющие сильно настраиваемые ошибки и рабочие процессы отчетов, полностью несовместимые системы сборки и т.д. И т.д. Однако нет никаких оснований для разделения файловой системы NTFS команды и команды MSPaint в отдельные проекты команды, даже если их фактическая работа никогда не дублируется; ни Windows 7 SP1 и Windows 8 не должны быть разделены, если только следующий этап релиза также не приведет к существенным изменениям процесса вместе с ним.

Как и в случае ветвления, я чувствую, что простота золотая. Когда у вас есть несколько проектов в команде, многие вещи, которые когда-то были мирскими задачами, внезапно становятся жесткими решениями. Скажем, вы обнаружили ошибку в базе данных sproc, которая была разработана в первую очередь другой командой. Открываете ли вы ошибку в своем командном проекте (чтобы убедиться, что он разрешен вам для подписания QA), в командном проекте другой команды (поскольку они будут теми, кто кодирует исправление) или в специальном DB-only командный проект? Сколько мест средний разработчик, как ожидается, будет искать активные рабочие элементы? Это только первый сценарий, который запомнился; есть много других функций, которые не переводят хорошо по проектам. К сожалению, есть также некоторые функции, которые требуют от вас разделить вещи. Если команда № 1 хочет использовать слияние "точно вовремя", но процесс разработки команды №2 зависит от эксклюзивных блокировок, которые просто не поддерживаются в рамках одного командного проекта.

Я использовал слово "процесс" несколько раз. Это действительно то, к чему это сводится. После того как вы поняли концепцию Шаблон процесса TFS, Team Projects имеют гораздо больший смысл. Здесь старый пост в блоге, где я расширяю эту идею, приводя к удобному эмпирическому правилу: создать один командный проект для каждого шаблона процесса. (Конечно, есть исключения, не все функции TFS можно контролировать с помощью шаблонов.) Более подробная информация доступна в в документе, который вызвал мой пост - - внутри вы найдете диаграмму с подробным описанием того, что/не поддерживается внутри/между отдельными командами. Я предполагаю, что небольшой магазин, такой как ваш, не потребует много компромиссов, чтобы он соответствовал одной модели Team Project, если таковой имеется.

Ответ 2

Для тех, кто по-прежнему заинтересован в том, как мы в итоге это сделали: нужен специалист по TFS, чтобы помочь!

Мы воспользовались этим: разбили все наши решения на свои проекты, поместили все проекты в соответствующие группы, разместили файлы .sln в каталоге Source, чтобы их было легко найти. Это был логичный способ организовать вещи, и он работал до сих пор.

<Branch>
Source
    Solution files at root
    Server Apps     Previously "services", helper apps running on server
        App 1
            Project 1
            Project N
            Installer
        App 2
    Services    WCF/Web services providing business operations
        App 1
            Project 1
            Installer
    Client      Rich client applications, e.g. WinForms, WPF
        App 1   
            Project 1
            Installer
    Web     Server side web applications
        App 1
            Project 1
            Installer
    Database    All scripts related to database structures and data
        Databases
            SMOL
            AuditAuthentication
            …
        Servers (Environments?)
            Server1.proj
            Server2.proj
    Common  Reusable classes across applications
        Communications
        Security
        ….
    SharedBin   3rd party binaries
        EnterpriseLibrary
        …
Docs
    Release notes
    Help files
Scripts
    Deployment
    Data Migration
    …
System Tests
    Functional
    Performance
    Security
    …

Вот как это выглядит в VS (некоторая путаница, чтобы защитить невинных)

Ответ 3

В этом случае я бы поместил проект базы данных в отдельный проект и просто ссылался на него из других проектов.

ИМХО, если ваша база данных (либо один экземпляр базы данных, либо просто общая схема базы данных) разделена между несколькими проектами, тогда вам необходимо обработать вашу схему базы данных (или, по крайней мере, ее большие части) в качестве интерфейса, открытого для этого проекта. Этот интерфейс /API должен контролироваться и управляться версиями независимо от любого проекта. Таким образом, база данных становится внешней зависимостью от всех этих проектов, как и любая разделяемая библиотека или сервер.

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

Добавьте к этому полное отсутствие поддержки зависимостей между проектами. Если вы хотите изменить зависимости между проектами, вам нужно либо развернуть проект как подпроект зависимого проекта (со всеми проблемами разветвления и слияния, о которых я упоминал выше), либо научить вашу систему сборки получать правильные версии из TFS все время (который я нахожу страшным).

Обратите внимание, что проект "Все" не поможет, если каждая его часть должна быть выпущена/выпущена отдельно. Вы упомянули "ветки функций" для подпроектов и т.д. Это будет еще хуже, чем отдельные проекты, которые, по крайней мере, являются явными. Если вы все открыто соглашаетесь поддерживать общий проект базы данных, не будет неожиданности, когда вы обнаружите, что вам нужно обсудить каждое изменение с ним среди всех ваших других проектных команд.

Итак, в конце концов, это ваше решение. Все ли проекты достаточно раздельные, чтобы их выпускать как отдельные проекты или нет. Они будут расходиться или нет. Вы хотите или хотите, чтобы они вообще расходились? Стоит ли стоимость дополнительной работы?

И на совершенно другом уровне. Все, о чем вы говорите, разбивает вашу базу кода вертикально на слои - здесь идет проект базы данных (с схемой базы данных и т.д.), Здесь доступ к данным, здесь бизнес-логика и т.д....

Вы рассматривали разделение по горизонтали на блоки уровня домена, каждый блок завершен и резервными копиями по его схеме базы данных. Ваш проект будет зависеть не только от общей схемы базы данных, но и от одного или нескольких общих модулей. И каждый из них привнесет свою часть скриптов базы данных.

Я просто думаю здесь. Я не уверен, что это будет лучше или если это будет даже на практике. Кто-нибудь может поделиться своим мнением?