ИСТОРИЯ
В течение своей карьеры я был удивлен тем, сколько проектов я видел, когда компиляция и выполнение проекта в Visual Studio является реальной проблемой. Источником проблемы обычно является отсутствие зависимостей, отсутствие документации, неработающие ссылки на проект и т. Д.
Чтобы избежать этих головных болей, я стараюсь автоматизировать проекты / решения таким образом, чтобы:
- среда выполнения автоматически настраивается, когда проект компилируется на машине разработчика (например, используйте пакетные сценарии для импорта отсутствующих ключей реестра Windows)
- при компиляции проекта автоматически извлекаются правильные зависимости (как на машине сборки, так и на машинах разработчика)
ПРОБЛЕМА
На сегодняшний день я добился значительных успехов с этим подходом. Однако недавно мне вручили собственный проект C ++, который зависит от Microsoft Windows SDK. Во время компиляции проект использует переменные среды Windows для поиска недостающих зависимостей (например, Microsoft Windows SDK).
Я понимаю, что использование переменных среды - это то, как раньше делалось. Однако, полагаясь на разработчика программного обеспечения для настройки среды разработки:
- вы предполагаете, что они правильно настроят среду
- разработчик тратит время на настройку, тогда как его время может быть лучше потрачено на разработку
Я не хочу обсуждать достоинства того, чтобы разработчик настраивал среду разработки, я хотел бы знать:
Учитывая существующую сегодня технологию (например, TFS), каков надежный и повторяемый подход к обработке больших зависимостей (например, Windows SDK) для проектов C ++ в командной среде?
ВОЗМОЖНЫЕ РЕШЕНИЯ
- continue to use environment variables
- Adv: once the dependencies are installed, it is very easy for the build machine to compile projects
- Dis: вам нужно потратить время на документирование, чтобы убедиться, что вы можете настроить машину сборки с нуля (например, шаг 1: установить зависимость A, шаг 2: установить зависимость B и т. Д.)
- Дис: Вы полагаетесь на магические переменные среды, которые указывают на правильную цель.
- Dis: разработчик тратит время на настройку, когда им следует разрабатывать
- check dependencies into TFS
- Adv: everything is kept in one centralized location
- Adv: изначально система контроля версий хранит историю
- Adv: в некотором смысле система контроля версий делает вещи самодокументированными
- Dis: Компиляция на машине сборки теперь занимает значительно больше времени, поскольку рабочая область машины сборки должна многократно извлекать Windows SDK из TFS.
- Другое?
КОНТЕКСТ
- Язык программирования: неуправляемый C ++
- Контроль версий: TFS 2012
- Dependencies:
- Microsoft Windows SDK (~416Mb)
- в домашних библиотеках
- У меня ограниченные знания о том, как администрировать / настраивать машину сборки TFS.
ССЫЛКИ
