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

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

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

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

Jmm

Ответы на вопрос(1)

Решение Вопроса

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

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

If you're making risky changes to your build scripts, make them in a "dev" or "private" branch, just as you would with any other risky changes. If you want a build definition that's just for quick validation, set properties like SkipLabel, SkipWorkItemCreation, etc to False in the *.targets file imported by that build definition.

Чтобы немного углубиться в №2, давайте возьмем ваш пример «производства» vs & quot; тест & quot; строит. Вам нужно только включить функции, такие как маркировка, в производственных сборках. Таким образом, вы удалили бы свойство 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 являются & quot; полными & quot; Сборки и сборки из ветви Main могут быть в зависимости от того, какое определение сборки пользователь запускает из Visual Studio / TSWA. Я "быстро" сборки, настроенные с помощью непрерывной интеграции и & quot; полная & quot; строит работает ночью.

 13 июл. 2009 г., 20:40
Я расширил пост конкретным примером - дайте мне знать, если это поможет.
 jMM13 июл. 2009 г., 18:46
Я видел, как вы пишете о модульных сборках команд, и, хотя это отличный подход к созданию сценариев сборки, мне нужна помощь в физическом процессе разработки сценариев сборки. Например, как предотвратить запуск сценария сборки, который не находится в & quot; производстве? от быть записанным как производственная сборка. Если это имеет смысл. Jmm
 19 мар. 2013 г., 12:03
Просто чтобы добавить обновление, может потребоваться ToolsVersion 4.0, но вы должны иметь возможность использовать что-то вроде<Import Condition="$(BuildDefinition.EndsWith(`quick`))" Project="MyCompany.TeamBuild.Quick.targets" /> вместо метода RegexReplace, упомянутого в комментариях.

Ваш ответ на вопрос