Что это?
Автоматическая сборка — это полностью автоматизированная компиляция конкретной версии вашего хранилища исходного кода, которая выполняется через регулярные промежутки времени. Чаще всего такая сборка включает в себя дополнительные этапы, такие как запуск статического анализа кода и покрытия кода, выполнение всех автоматических модульных и интеграционных тестов и, возможно, даже полномасштабное развертывание продукта и базы данных на тестовом сервере. Непрерывная интеграция, или CI, — это просто причудливое имя, говорящее о том, что сборка запускается всякий раз, когда разработчик регистрирует свои изменения в репозитории исходного кода. По сути, это заставляет всех разработчиков постоянно интегрировать свои изменения в работающий продукт. Тем не менее, поскольку сборки такого типа выполняются очень часто, дополнительные шаги обычно ограничиваются модульными тестами и покрытием кода.
Зачем ты это делаешь?
- Поскольку два разработчика, каждый из которых работает в одной и той же области базы кода, не могут в полной мере гарантировать, что их изменения не вызовут каких-либо функциональных проблем.
- Поскольку развертывание нового выпуска на сервере разработки, тестирования или приемки обычно включает в себя множество шагов вручную, каждый из которых очень подвержен ошибкам.
- Потому что развертывание вашего продукта или системы в автоматическом режиме требует, чтобы он был создан для этого. Внедрение автоматического ежедневного развертывания заставляет вас решать возможные проблемы на ранних этапах проекта, которые в противном случае не возникли бы до окончательной даты выпуска.
- Потому что тогда становится тривиальным повторное развертывание более ранней версии вашего продукта или системы, например, когда новый выпуск содержит некоторые критические ошибки, и вы хотите выполнить откат, или проанализировать функциональные изменения между версиями.
Какой минимум ты должен сделать?
- Используйте непрерывную интеграционную сборку, которая компилирует ваши решения и запускает ваши модульные тесты.
Что обычно делать?
- Разверните самую последнюю версию вашего продукта или системы на центральном сервере разработки.
- Автоматическое развертывание изменений схемы базы данных и тестирование данных в вашей центральной базе данных.
- Включите шаг сборки, который назначает уникальный номер версии всем исполняемым файлам и библиотекам DLL, чтобы вы могли легко увидеть, какая версия развернута.
Как ты это делаешь?
Настройте сборку Continuous Integration в Team Foundation Server 2008 или 2010, выполнив следующие действия:
- Создайте отдельное определение сборки в Team Build 2008 или Team Build 2010 для каждого решения, связанного с вашим продуктом или системой, и настройте его так, чтобы оно запускалось при каждой регистрации.
- Не забудьте настроить свое определение для создания версии выпуска вашего решения.
- При желании настройте сборку, чтобы включить анализ кода с использованием параметров проекта. Прочтите этот пост о том, как настроить это с помощью шаблона по умолчанию в Team Build 2010.
- Используйте элемент <TestContainer>, чтобы указать, какие тестовые сборки нужно проверять на предмет модульных тестов, или используйте подстановочный знак, например * \ ** \ *. Specs.dll, чтобы запустить все тесты в сборках, исправленных после .specs.dll.
- Если вашим тестам нужен определенный .testrunconfig, откройте базовый файл build.proj и добавьте элемент <RunConfigFile>, как описано в этом посте.
- Обратите внимание, что в Team Build 2010 вы можете пропустить два предыдущих шага и использовать вместо этого диалоговое окно «Определение сборки». Смотрите этот пост для получения дополнительной информации.
- Убедитесь, что вы поддерживаете быструю сборку CI, например, только запуская модульные тесты, которые не зависят от медленных ресурсов, таких как ввод-вывод, базы данных и т. Д.
- Вы можете ускорить сборку, включив инкрементную сборку и отключив шаг, на котором результаты копируются в выделенную сетевую папку размещения (настраивается через свойство <SkipDropBuild> .
Настройте ежедневную сборку в Team Build 2008, которая развертывает последнюю версию на выделенном тестовом сервере, выполнив следующие действия.
- Используйте отдельные конфигурации решения, чтобы параметры проекта были специфичны для среды развертывания. Таким образом, в дополнение к стандартной конфигурации выпуска и отладки, вы можете ввести конфигурации тестирования, принятия и производства.
- Введите альтернативные файлы .config, связанные с конкретными конфигурациями решения, например, например, web.production.config или предприимчивая библиотека.production.config и настройте Team Build 2008 для развертывания правильной версии с использованием этого блока в проекте веб-приложения:
<Target Name="AfterBuild" Condition="('$(Configuration)' != 'Debug') and ('$(Configuration)' != 'Release')">
<!-- If a configuration-specific web.config exists, replace the default web.config with it –> <Copy Condition="Exists('$(DeploymentFolder)\web.$(Configuration).config')" SourceFiles="$(DeploymentFolder)\web.$(Configuration).config" DestinationFiles="$(DeploymentFolder)\web.config" />
<Delete Files="$(DeploymentFolder)\web.$(Configuration).config" />
<!-- If a configuration-specific enterpriselibrary.config exists, replace the default enterpriselibrary.config with it –> <Copy Condition="Exists('$(DeploymentFolder)\enterpriselibrary.$(Configuration).config')" SourceFiles="$(DeploymentFolder)\enterpriselibrary.$(Configuration).config" DestinationFiles="$(DeploymentFolder)\enterpriselibrary.config" />
<Delete Files="$(DeploymentFolder)\enterpriselibrary.$(Configuration).config" />
</Target>
- Если вы используете Visual Studio 2010, вы можете уменьшить количество совпадений между этими альтернативными файлами .config с помощью файлов преобразования конфигурации .
- Чтобы развернуть веб-сайт с помощью Team Build 2008 без проекта веб-развертывания, настройте .csproj вашего проекта веб-приложения для автоматического развертывания всего веб-сайта на выделенном сервере, используя следующий пример конфигурации. Обратите внимание, что вам нужно установить для свойства $ (DeploymentFolder) допустимый UNC-путь.
<Target Name="AfterBuild" Condition="('$(Configuration)' != 'Debug') and ('$(Configuration)' != 'Release')">
<Message Text="Deploying Web Site to '$(DeploymentFolder)'." Importance="high" />
<!-- Create the _PublishedWebsites\app\bin folder –> <MakeDir Directories="$(DeploymentFolder)\bin" />
<!-- Copy build outputs to $(DeploymentFolder)\bin folder. –> <Copy SourceFiles="@(IntermediateAssembly)" DestinationFolder="$(DeploymentFolder)\bin" SkipUnchangedFiles="true" />
<Copy SourceFiles="@(AddModules)" DestinationFolder="$(DeploymentFolder)\bin" SkipUnchangedFiles="true" />
<Copy SourceFiles="$(IntermediateOutputPath)$(_SGenDllName)" DestinationFolder="$(DeploymentFolder)\%(Content.SubFolder)%(Content.RecursiveDir)" SkipUnchangedFiles="true" Condition="'$(_SGenDllCreated)'=='true'" />
<Copy SourceFiles="$(IntermediateOutputPath)$(TargetName).pdb" DestinationFolder="$(DeploymentFolder)\bin" SkipUnchangedFiles="true" Condition="'$(_DebugSymbolsProduced)'=='true'" />
<Copy SourceFiles="@(DocFileItem)" DestinationFolder="$(DeploymentFolder)\bin" SkipUnchangedFiles="true" Condition="'$(_DocumentationFileProduced)'=='true'" />
<Copy SourceFiles="@(IntermediateSatelliteAssembliesWithTargetPath)" DestinationFolder="$(DeploymentFolder)\bin" SkipUnchangedFiles="true" />
<Copy SourceFiles="@(ReferenceComWrappersToCopyLocal); @(ResolvedIsolatedComModules); @(_DeploymentLooseManifestFile); @(NativeReferenceFile)" DestinationFolder="$(DeploymentFolder)\bin" SkipUnchangedFiles="true" />
<!-- copy any referenced assemblies to $(DeploymentFolder)\bin folder –> <Copy SourceFiles="@(ReferenceCopyLocalPaths)" DestinationFolder="$(DeploymentFolder)\bin" SkipUnchangedFiles="true" />
<!-- Copy content files recursively to $(DeploymentFolder)\bin folder –> <Copy SourceFiles="@(Content)" DestinationFolder="$(DeploymentFolder)\%(Content.RelativeDir)" />
</Target>
- Чтобы развернуть веб-сайт с использованием типа проекта Web Deployment в типе проекта Visual Studio 2010, прочитайте этот пост.
- Чтобы развернуть веб-сайт с помощью Team Build 2010 и MSDeploy, прочитайте этот пост.
- Если вы хотите автоматически добавить увеличенный номер версии ко всем сборкам, используя Team Build 2008, прочитайте этот пост. Если вы хотите сделать это с помощью Team Build 2010 с шаблоном обновления, прочитайте это . И если вы хотите использовать шаблон по умолчанию, прочитайте это .
Если вы также хотите
развернуть базу данных автоматически, включите следующие дополнительные шаги.
- Установите Visual Studio Team System 2008 Database Edition и GDR R2 . Вам не нужно никаких дополнительных лицензий для этого.
- Импортируйте схему и конфигурацию своей базы данных, используя проект базы данных.
- Настройте проект базы данных так, чтобы конкретная база данных была связана с конкретной конфигурацией решения. Например, локальная сборка должна развертывать вашу базу данных на локальном ПК для разработки, в то время как Daily Build должна развертывать ее на центральном сервере баз данных.
- Добавьте выделенную цель AfterDropBuild в build.proj вашего определения сборки, чтобы построить и развернуть проект базы данных в настроенной базе данных:
<Target Name="AfterDropBuild">
<MSBuild Projects="$(SolutionRoot)\Main\Source\ConstructIT\Database\Database.dbproj" Properties=" OutDir=$(OutDir)" Targets="Deploy"/>
</Target>
- Для получения дополнительной информации о развертывании базы данных с использованием Visual Studio 2008 читайте блог Gert Drapers .
- Это также работает с шаблоном обновления Team Build 2010, но если вы хотите сделать это с шаблоном по умолчанию, выполните действия, описанные в этом посте .
Другие советы и предложения
- Договоритесь с вашей командой, что первыми, кто придет утром в офис, будут отвечать за проверку состояния сборки, а в случае сбоя одного из них — решение проблемы.
- Запишите все важные сведения о сборке (такие как типичные проблемы, подробности о каждой сборке и т. Д.) На своем проекте или сайте отдела и убедитесь, что существует более одного члена команды, который знает, как настроить или адаптировать сборку.
- Используйте инструмент уведомления о сборке в TFS Power Tools, чтобы следить за сборкой через соответствующий значок на панели задач Windows.
- Вы можете настроить определение сборки Team Build 2008 (или шаблон обновления 2010), используя множество свойств, упомянутых на этом сайте .
- Большая часть руководства предназначена для Team Build 2008, но также будет работать с шаблоном обновления Team Build 2010 . Однако, если вы хотите узнать, как извлечь максимальную пользу из шаблона по умолчанию для рабочего процесса, ознакомьтесь с этой серией публикаций, написанных MVP Эвальдом Хофманом .