Работа с конвейерами сборки (или определениями сборки, build pipelines/build definitions)

Если у вас уже есть опыт разработки Dynamics 365 for Finance and Operations, вы, скорее всего, знакомы с настройкой системы сборки. Если нет, вам следует начать с официальной документации. Кроме того, вы можете прочитать мою статью по настройке виртуальной машины локальной сборки.

Но настройка одной сборочной машины — это только начало. С помощью конвейеров сборки Azure DevOps (ранее известных как определения сборки Visual Studio Team Services) вы получаете полный контроль над процессом сборки. Вы также можете создать несколько процессов сборки для разных сценариев, чтобы вы могли легко работать с несколькими ветками, внутренними / демонстрационными / релизами и так далее.

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

Что такое конвейер сборки?

Конвейер сборки — это набор параметров, управляющих процессом сборки. Параметры включают в себя такие вещи, как какая ветка системы управления версиями будет использована, настраиваемые сценарии PowerShell и триггеры (плановая сборка или непрерывная интеграция / сборка после каждого коммита кода). Конвейеры сборки не являются уникальными для Dynamics 365 for Finance and Operations, вместо этого D365FO использует эту уже существующую функцию Azure DevOps.

При развертывании машины для сборки D365FO (топология «Сборка и тестирование»/ “Build and Test”) из Lifecycle Services в Azure DevOps создается конвейер сборки по умолчанию. Наименование конвейера сборки по умолчанию – «[Имя вашего проекта Azure DevOps] – Build Main».

Управление конвейерами сборки

Существующие конвейеры сборки можно найти в Azure DevOps, перейдя к Конвейеры – Сборки (Pipelines – Builds) в левой части навигации. По умолчанию там отображаются конвейеры с последними сборками, поэтому, если вы только что создали новый конвейер, вам нужно переключиться в представление в виде папок (помечено красным на рисунке), чтобы увидеть все конвейеры сборки.

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

Важные настройки

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

Пул агентов

На главном экране режима редактирования конвейера сборки вы можете изменить пул агентов конвейера. Обычно вам не требуется менять его. При развертывании среды для сборки из Lifecycle Services вы можете выбрать, какой пул агентов вы хотите использовать. Одной из возможностей является использование разных пулов агентов для каждой среды D365FO, которую вам нужно собрать. Таким образом, вы можете, например, назначить определения сборки для D365FO версии 8.0 PU15 для пула агентов, который имеет машину сборки с той же версией, и так же другой пул агентов и другой набор определений сборки для среды версии 8.1 PU20.

Ветка

Вы можете указать, какая ветка (branch) приложения будет собираться, с помощью этих двух настроек «Получить исходники» (“Get sources“) и «Собрать решение» (“Build the solution“):

Пользовательские сценарии сборки

Вы можете добавлять свои собственные скрипты PowerShell в процесс сборки. Эти скрипты должны быть размещены на компьютере сборки в папке “C:\DynamicsSDK”. Я написал статью, которая иллюстрирует, как добавить скрипт, который вычисляет количество перекрытых (overlayered) объектов при каждой сборке. Несмотря на то, что этот конкретный сценарий вскоре станет ненужным для всех клиентов D365FO (поскольку перекрытие в последней версии больше недоступно, инструкция из статьи подойдет для включения любого другого сценария, который может вам понадобиться в процессе сборки).

Переменные

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

Если вам нужен только развертываемый пакет, вы можете использовать «SkipSourcePackageGeneration», чтобы пропустить создание пакета модели. Если у вас есть пакет для юнит-тестов, вы можете исключить его из развертываемого пакета с помощью переменной «PackagingExclusion».

Триггеры

Вы можете использовать триггеры, чтобы контролировать, когда сборка должна начаться.

Непрерывная интеграция (Continuous integration) означает, что сборка запускается после каждого коммита. Коммит с контролем качества (Gated check in) означает, что код должен быть успешно собран до того, как коммит будет принят. Поскольку сборка D365FO может занимать достаточно много времени, вам следует рассмотреть возможность использования настроек, описанных в главе «Переменные», чтобы сократить время сборки, если вы хотите использовать эти функции.

Вы также можете использовать обычную сборку по расписанию для сборки кода днем или по ночам.

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

Сколько определений сборки мне понадобится?

На этот вопрос нет однозначного ответа. В моей практике работы на независимого поставщика ПО я нахожу, по крайней мере, следующие конвейеры очень полезными:
– Ежедневная или ночная сборка – результат будет развернут на внутренней тестовой среде. Поскольку на момент написания статьи автоматическое развертывание в изолированной среде песочницы Microsoft через LCS невозможно, я предпочитаю выполнять сборку ближе к вечеру, чтобы результат мог быть загружен в LCS и применен к тестовой среде в конце каждого дня.
– Релизный – этот конвейер используется для сборки официальных релизных пакетов
–  Для поддержки – вам, очевидно, понадобится ветка поддержки для всех выпущенных версий и конвейер сборки для каждой ветки.
–  Демонстрационная – многие независимые поставщики программного обеспечения имеют демонстрационные и / или функции-прототипы, которые необходимо обрабатывать отдельно от актуального кода продукта. Имеет смысл иметь отдельный конвейер для демо-ветки.

Оригинал статьи доступен по следующей ссылке.