Ответ 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, если таковой имеется.
