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

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

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

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

1. все ветви автономны. между ветвями не допускаются зависимости, или между ветвью и фиксированным (неразветвленным) местоположением
2. относительные пути внутри ветвей инвариантны
3. Модель продвижения хорошо определена и одинаково применима ко всем инженерным артефактам: разработка -> интеграция -> производство (если использовать их термины) для первичных кодовых строк; многие другие широко используются, обычно составляя ту же основную идею)
4. 1 Интеграционная ветвь (также известная как Магистраль, также известная как Главная), которая связывает стабильные и нестабильные стороны дерева. одноранговое слияние не допускается.
5. переменная # ветвей Dev в зависимости от степени изоляции, необходимой между командами / функциями / рефакторами
6. переменная # ветвей выпуска в зависимости от частоты исправлений, перекрываются ли какие-либо выпуски, и насколько строги требования аудита
7. , если вы решите проверять вторичные ресурсы, такие как документация, сторонние двоичные файлы, компиляторы и т.д., они входят в структуру ветвей. см. правило № 1.

... вместе с некоторыми особенностями TFS ...

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

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

В любом случае, я знаю, что вы спрашивали не о ветвлении и слиянии конкретно, а о том, как вы Расположение исходного дерева имеет прямое отношение к вашему программному процессу в целом. Откровенно говоря, если вы не будете следовать правилам, подобным №1, при добавлении проекта базы данных, ваши команды разработчиков интерфейсных приложений никогда не смогут работать независимо. Как таковой, ваше первое предложение (структура, изображенная в разделе $ / FrontOfficeDevelopment) намного ближе к цели, чем второе. Но нужно идти дальше. Переместите папки для 3 приложений + базы данных на один уровень глубже в дереве. Т.е. дайте им общего родителя - назовем его «Интеграция», чтобы соответствовать другому примеру StackOverflow. Если вам когда-нибудь понадобится ветвление, теперь вы можете сделать это одним автономным действием, разветвив этот контейнер; было бы намного сложнее, если бы каждое приложение было папкой верхнего уровня в командном проекте. Вскоре ваше дерево исходных текстов будет выглядеть так же, как идеалы, изображенные на диаграммах "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, что удобно, если ваши приложения очень большие или их десятки или сотни. Однако в равной степени можно создать одну папку Tests верхнего уровня внутри ветви, как показано ниже:

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

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

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

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

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

Я уже несколько раз использовал слово «процесс». Это действительно то, к чему все сводится. Как только вы поймете концепцию шаблона процесса TFS , командные проекты приобретут гораздо больший смысл. Вот старый пост в блоге , где я расширяю эту идею, приводя к удобному практическому правилу: создавайте один командный проект для каждого шаблона процесса . (Конечно, есть исключения; не всеми функциями TFS можно управлять с помощью шаблонов.) Более подробная информация доступна в техническом документе, который вызвал мою публикацию - внутри вы найдете диаграмму с подробным описанием того, что / не является Не поддерживается внутри / между отдельными командными проектами. Думаю, это небольшой магазинчик вроде твоего выиграл

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

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

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

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

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

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

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

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

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

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

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

<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 (некоторая обфускация для защиты невиновных)