Как сделать локальный запуск TFS Build удобным
01/04/2010 Оставьте комментарий
Если ваш проект состоит не только из управляемого кода, и Вы используете Team Build, то, скорее всего, Вы уже заметили, что сборка solution на build машине не всегда проходит также гладко, как в IDE. К сожалению, порядок сборки проектов может отличаться, да и изменения исходных файлов не всегда отсеживаются корректно.
Хоть это и происходит редко, последствия крайне неприятны, особенно в том случае, если Вы используете непрерывную сборку. Представьте – разработчик собирает в IDE проект, и со спокойной душой кладёт изменения в систему контроля версий. Далее происходит сборка продукта и она ломается. Разработчик в недоумении. Все поледующие изменения, внесённые другими членами команды тоже приводят к сломанной сборке и проблема растёт как снежный ком (ну, конечно, если у Вас нет TFS 2010 и gated chek-in).
В среднестатистической команде, далеко не каждый разработчик в состоянии разобраться с подобной проблемой.
В любом случае, чтобы убедиться в том, что проблема исправлена, необходимо собрать проект на машине разработчика так же, как его собирает Team Build.
В принцепе, это можно сделать из командной строки, натравив MSBuild на файл сборки TFSBuild.proj. На первый взгляд, задача выглядит не сложной. Но это только в том случае, если структура папок в системе контроля версий у Вас выбрана по-умолчанию. Если же, например, в одном проекте Вы храните разные ветки продукта, делаете ветвления (что очевидно для грамотной разработки проекта), то файл TFSBuild.proj, с большой долей вероятности, лежит в другом месте. В моём случае, есть следующая структура проектов:
Проблема заключается в том, что умолчательные пути для результата сборки и тестов будут располагаться по вот такому пути “..\..\Binaries” и “..\..\TestResults” соответсвенно. Это ещё половина беды, так как самое страшное в этом случае то, что результат сборки будет просто выше по иерархии. Это не красиво, но не смертельно. Хуже другое – запуск коммандной строки
MSBuild TFSBuild.proj
в папке Build, где у меня лежит файл проекта сборки, просто сломается. Дело в том, что MSBuild будет искать solution файл в папке “..\..\Sources”. В моём случае не обойтись без параметров:
MSBuild TFSBuild.proj –p:SolutionRoot=..\
Согласитесь, что вспоминать все эти параметры в тех редких случаях, когда надо отладить процесс локальной сборки, не очень удобный вариант. Элегантное решение – поправить файл проекта таким образом, чтобы действовали умолчания, удобные Вам. Вставлю следующий кусок в проектный файл:
<PropertyGroup>
<!-- Set default paths for desktop build -->
<BuildDefinition Condition=" '$(IsDesktopBuild)' != 'false' and '$(BuildDefinition)' == '' ">DesktopBuild</BuildDefinition>
<SolutionRoot Condition=" '$(IsDesktopBuild)' != 'false' and '$(SolutionRoot)' == '' ">$(MSBuildProjectDirectory)\..\</SolutionRoot>
<DesktopBuildOutputRoot Condition=" '$(IsDesktopBuild)' != 'false' and '$(DesktopBuildOutputRoot)' == '' ">$(MSBuildProjectDirectory)\..\TfsDesktopBuild</DesktopBuildOutputRoot>
<BinariesRoot Condition=" '$(IsDesktopBuild)' != 'false' and '$(BinariesRoot)' == '' ">$(DesktopBuildOutputRoot)\Binaries</BinariesRoot>
<TestResultsRoot Condition=" '$(IsDesktopBuild)' != 'false' and '$(TestResultsRoot)' == '' ">$(DesktopBuildOutputRoot)\TestResults</TestResultsRoot>
</PropertyGroup>
Обращаю внимание, что сделать это надо до строки импорта TFS build проекта:
<!-- Do not edit this -->
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" />
<ProjectExtensions>
В своей реализации я оставил возможность для эстетов таки переопредилить и мои умолчания 🙂
Теперь Вам будет легче убедить своих разработчиков отлаживать любые проблемы локально на своей машине, а не “тренироваться на кошечках”.