Управление SDLC для сценариев сборки TFS - PullRequest
Новая
       27

Управление SDLC для сценариев сборки TFS

1 голос
/ 10 июля 2009

Я нахожусь в процессе разработки нескольких пользовательских сценариев сборки для TFS, и я хотел бы знать, есть ли какие-либо рекомендации по разработке, тестированию и развертыванию сценариев сборки TFS.

Настраиваете ли вы среды разработки и контроля качества, отделенные от сервера производственной сборки? Существуют ли другие способы изолировать процесс разработки сценариев от остальной части процесса сборки, чтобы разрабатываемые сценарии сборки не мешали «производственным» сборкам?

Team Build любит создавать рабочие элементы, обновлять рабочие элементы и добавлять метки как часть процесса сборки, чего я бы предпочел не делать для «тестовой» сборки.

Jmm

1 Ответ

3 голосов
/ 10 июля 2009

Проверьте мой ответ здесь: Модульная TeamBuilds

Вы можете сохранить основные функциональные возможности в виде общего файла MSBuild, который включен во все сборки. Кроме того, все эти файлы являются частью вашей более широкой структуры ветвей, поэтому они принимают непосредственное участие в вашем существующем SDLC без какой-либо дополнительной работы. Таким образом:

  1. Если вы вносите рискованные изменения в свои сценарии сборки, сделайте их в "dev" или "private" ветке, так же, как и при любых других рискованных изменениях.
  2. Если вам нужно определение сборки, предназначенное только для быстрой проверки, задайте для таких свойств, как SkipLabel, SkipWorkItemCreation и т. Д. Значение False, в файле * .targets, импортированном этим определением сборки.

Чтобы немного расширить # 2, давайте возьмем ваш пример сборок «production» против «test». Вам нужно только включить функции, такие как маркировка, в производственных сборках. Поэтому вы должны удалить свойство SkipLabel из TFSBuild.proj (а также TFSBuild.Common.targets, если оно там определено) и вместо этого установить его в TFSBuild.Production.targets и TFSBuild.Test.targets - конечно, используя два разных значения.

Как упоминалось в предыдущем вопросе, TFSBuild.proj - это основной файл msbuild, который управляет работой остальной части сборки. Вот как выглядит моя шахта: 

<?xml version="1.0" encoding="utf-8"?>

<!-- DO NOT EDIT the project element - the ToolsVersion specified here does not prevent the solutions 
     and projects in the SolutionToBuild item group from targeting other versions of the .NET framework. 
     -->
<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

    <!-- Import configuration for all MyCompany team builds -->
    <Import Project="MyCompany.TeamBuild.Common.targets"/>

    <!-- Import build-specific configurations -->  
    <Import Condition="'$(BuildDefinition)'=='Dev - quick'"     Project="MyCompany.TeamBuild.Quick.targets" />
    <Import Condition="'$(BuildDefinition)'=='Main - full'"     Project="MyCompany.TeamBuild.Full.targets" />
    <Import Condition="'$(BuildDefinition)'=='Main - quick'"    Project="MyCompany.TeamBuild.Quick.targets" />
    <Import Condition="'$(BuildDefinition)'=='Release - full'"  Project="MyCompany.TeamBuild.Full.targets" />

    <!-- This would be much cleaner as we add more branches, but msbuild doesn't support it :(
         Imports are evaluated declaratively at parse-time, before any tasks execute
    <Target Name="BeforeEndToEndIteration">
      <RegexReplace Input="$(BuildDefinition)" Expression=".*\s-\s" Replacement="">
        <Output TaskParameter="Output" PropertyName="BuildType" />
      </RegexReplace>
    </Target>
    <Import Condition="$(BuildType)==full"  Project="MyCompany.TeamBuild.Full.targets" />
    <Import Condition="$(BuildType)==quick" Project="MyCompany.TeamBuild.Quick.targets" />
    -->
</Project>

Делая что-то похожее, вы можете убедиться, что все сборки из ветви Dev являются "быстрыми" сборками (что для вас означает отсутствие маркировки и т. Д.), Все сборки из ветви Release являются "полными" сборками и сборками из Основная ветвь может быть в зависимости от того, какое определение сборки пользователь запускает из Visual Studio / TSWA. У меня есть "быстрые" сборки, настроенные с помощью непрерывной интеграции, и "полные" сборки, работающие по ночам.

...