Можно ли использовать одно определение сборки TFS 2010 для нескольких ветвей?

Question

Я слежу за сборками наших продуктов, и меня попросили придумать способ настройки существующего определения сборки, чтобы при необходимости создавать разные ветви.

Процесс сборки для этого продукта уже имеет несколько пользовательских шагов и действий, и у продукта есть большое количество файлов проекта, которые создаются, поэтому неэффективно устанавливать новое определение сборки для каждой новой создаваемой ветви.

Определение сборки настроено на сборку из ветви Main. Цель состоит в том, чтобы ввести определенную ветвь (используя аргумент рабочего процесса, который можно ввести, когда сборка ставится в очередь), которая затем будет построена вместо основной ветви по умолчанию без необходимости редактировать определение сборки.

У меня есть отдельная тестовая программа, которую я использую для тестирования всех своих пользовательских действий и процедур сборки. В рабочем процессе для этого определения сборки я добавил довольно много сообщений о сборке для целей регистрации, чтобы я мог просматривать значения переменных, используемых в процессе сборки.

Я также создал ветку на основе этой тестовой программы, готовую для тестирования определения сборки, которое можно использовать для создания более одной ветки

Во-первых, я запустил сборку для исходных файлов проекта тестового решения из исходной ветви, затем изменил определение сборки так, чтобы то же самое было сделано с использованием новой ветви, и запустил другую сборку. При сравнении журналов сборки между двумя ветвями между ними есть только несколько незначительных различий. (Детализация ведения журнала установлена ​​на Диагностика)

1-е отличие - я посмотрел переменную Workspace, и свойство Folders компоновок ссылается на их соответствующие ветви, в частности, свойство ServerItem свойства Folders

2-е отличие - создаваемые файлы проекта (BuildSettings.ProjectsToBuild) поступают из соответствующих ветвей

Я не видел никаких других отличий между 2 журналами сборки, кроме этих

Главный вопрос здесь :

Существует ли стандартный способ замены веток, создаваемых для одного определения сборки?

Если нет, можно ли просто изменить все ссылки на основную ветку по умолчанию в настроенном шаблоне рабочего процесса (в Workspace и BuildSettings.ProjectsToBuild) на введенную ветвь при постановке в очередь на сборку?

Как всегда, заранее спасибо за любую помощь

Answer 1

Мне удалось изменить шаблон рабочего процесса моей сборки, чтобы были возможны сборки для нескольких веток решения.Чтобы добиться этого, мне пришлось изменить некоторые вещи в рабочем процессе, а также создать несколько дополнительных рабочих пространств для учетной записи службы, которая запускает сборки.

1. Я добавил аргумент в рабочий процесс, чтобы необходимыеветвь может быть введена, когда сборка находится в очереди.

2. Я изменил место отбрасывания для сборки, чтобы оно соответствовало введенной ветке (необязательно)

3. Создал отдельный каталог источников на компьютере сборки для сборки ветки

4. Инициализировал WorkspaceName и SourcesDirectory, чтобы они соответствовали новому имени рабочего пространства и папке каталога источников

5. Я создал пользовательское действие, чтобы изменить список проектов / решений в BuildSettings.ProjectsToBuild, чтобы они ссылались на них из введенной ветви

6. Я заметил черезмоя фаза тестирования, что, хотя мое новое рабочее пространство для введенной ветви было изначально настроено на использование введенной ветвив качестве своего ServerItem он по-прежнему создает рабочее пространство с ServerItem, который был введен в определение сборки.Чтобы обойти это, я создал другое настраиваемое действие, чтобы переназначить рабочее пространство ветви так, чтобы ServerItem указывал на правильную ветку

Есть несколько других вещей, которые я включил в свой рабочий процесс, но они являются более тонкими настройками, запрошенными моими разработчиками, приведенные выше шаги привели к нескольким сборкам веток для одного определения сборки.

Answer 2

Я знаю, что это очень старая версия, но на тот случай, если кто-нибудь найдет эту запись.

У нас такое же требование: возможность создать ветку функции, чтобы обеспечить сборку конкретной функции, используемой для тестирования перед объединением.в разработку.

Вот как мы это сделали:

Создан набор расширений Visual Studio:

• Создание сборки ветки
• Запуск сборки ветки
• Удалить ветку

Создание сборки ветки клонирует определение сборки, которое используется в качестве шаблона.Измените имя определения сборки и рабочее пространство на основе ветви.Определение сборки будет отображаться в Team Explorer (VS2012).

Запустить сборку ветки найдет определение сборки и запустить сборку.

Удалить ветку найдет определение сборки, удалить все сборки,удалите определение сборки и удалите ветку (Очистить).Сборки и ветвь имеют короткий срок службы, поэтому важно, чтобы они были очищены.

Answer 3

Я также хотел, чтобы в моих определениях сборки была более гибкая ветвь, поэтому я реализовал кодовое действие для изменения ProjectsToBuild (как шаг 5 Vermin выше). Вот код (удалены специфичные для проекта вещи):

[BuildActivity(HostEnvironmentOption.All)]
public sealed class ConvertProjectsAccordingToBranch : CodeActivity
{
    public static string s_MainBranch = "$/MyTeamProject/Main";

    public InArgument<IBuildDetail> BuildDetail { get; set; }
    public InArgument<BuildSettings> BuildSettingsOriginal { get; set; }
    public OutArgument<BuildSettings> BuildSettingsConverted { get; set; }

    protected override void Execute(CodeActivityContext context)
    {
        Logger.Instance.Init(context);
        IBuildDetail buildDetail = BuildDetail.Get(context);
        BuildSettingsConverted.Set(context, ConvertProjects(BuildSettingsOriginal.Get(context), buildDetail.BuildDefinition));
    }

    /// <summary>Returns a BuildSettings with ProjectsToBuild converted according to the build definition's workspace</summary>
    public BuildSettings ConvertProjects(BuildSettings settingsOriginal, IBuildDefinition buildDefinition)
    {
        var mappings = buildDefinition.Workspace.Mappings;
        if (mappings.Count() != 1)
        {
            throw new BuildProcessException(string.Format(CultureInfo.InvariantCulture,
                "Build definition must have exactly one workspace mapping. Build definition ID:{0} has {1} mappings",
                buildDefinition.Id,   // IBuildDefinition doesn't have any Name property, seriously!
                mappings.Count()));
        }

        string definitionBranch = mappings.First().ServerItem;
        var settingsConverted = new BuildSettings()
        {
            PlatformConfigurations = settingsOriginal.PlatformConfigurations,
        };

        foreach (string projectOriginal in settingsOriginal.ProjectsToBuild)
        {
            var projectConverted = projectOriginal.Replace(s_MainBranch, definitionBranch);
            if (!projectConverted.StartsWith(definitionBranch))
            {
                throw new BuildProcessException(string.Format(CultureInfo.InvariantCulture,
                    "Project {0} is not under main branch {1},  Definition branch: {2}",
                    projectOriginal, s_MainBranch, definitionBranch));
            }

            settingsConverted.ProjectsToBuild.Add(projectConverted);
            Logger.Instance.Log("Converted ProjectToBuild: {0},  original: {1}", projectConverted, projectOriginal);
        }

        return settingsConverted;
    }
}

У меня также есть модульный тест для ConvertProjects(), но он зависит от локального материала, поэтому я не публиковал его здесь. Это тривиально, и, безусловно, стоит написать!

Answer 4

Короче говоря: Нет и Да: -)

Немного более детально проработав эти ответы, системные шаблоны TFS по умолчанию предпочитают иметь одно определение сборки для каждой ветви, которую вы хотите построить, или указать все ветви.это должно быть построено на месте, но в единственном определении сборки.Не существует стандартного способа выбора из доступных ветвей в диалоговом окне Очередь новой сборки .

Следующим ответом будет «Да», потому что действительно вы можете настроить шаблон сборки, и я понимаю,ты уже начал это делать.В зависимости от вашей структуры ветвления должно быть довольно легко добавить свойство в шаблон, которое отображается в диалоговом окне «Новая сборка очереди», и иметь (например) строку, разделенную полуколоннами, со всеми ветвями, которые вы хотите построить во время выполнения,И для каждого элемента в этом списке добавьте решение для встраивания процесса рабочего процесса до того, как шаблон фактически начнет итерацию этого списка.

Это должно сделать работу, однако мне интересно, как вы в конечном итоге захотелиэта способность?Вы не используете файлы решений VS?