Используем Azure pipelines для 1С

Почему Azure?

 

Во многих компаниях наряду с 1С используются другие технологические стеки, в частности – стек от Microsoft, который при наличии DevOps-подхода в разработке подразумевает использование инструментов Azure DevOps. В таком случае возникает вопрос – зачем разводить “зоопарк” из других решений специально для 1С и нельзя ли использовать существующие инструменты и экспертизу?

На текущий момент могут также возникнуть опасения вида: «Разве Microsoft не ушла с нашего рынка? Разве они нас не бросили?»

На самом деле, это не совсем так. Azure DevOps — это не только облачный сервис, но и on-premise решение, которое можно развернуть в собственной инфраструктуре (и часто оно уже развернуто для не-1С решений).

Попробуем разобраться, как применить существующие инструменты Microsoft для разработки, тестирования и развертывания 1С решений.

 

Компоненты Azure DevOps

 

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

• Azure Boards — встроенный инструмент управления проектами и задачами. Он поддерживает работу с пулами задач (backlog), Kanban-досками, планирование спринтов и трекинг задач. По функциональности его можно сравнить с Jira.

• Azure Repos — это Git-репозитории, обеспечивающие хранение исходного кода. Предоставляет возможности для ведения версий, ветвления, pull-реквестов и код-ревью. По сути, является аналогом GitHub или GitLab, но с глубокой интеграцией c остальными компонентами.

• Azure Pipelines — ядро CI/CD в Azure DevOps. Отвечает за автоматизацию сборки, тестирования и развертывания приложений. Поддерживает как облачные, так и on-premise агенты, которые выполняют задачи на выделенных сборочных узлах. Агенты могут быть развернуты на виртуальных машинах, в контейнерах или локальных серверах.

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

• Azure Artifacts — служба для хранения и управления артефактами сборки, такими как пакеты NuGet, npm и другие. Позволяет обмениваться промежуточными результатами между различными этапами и узлами сборочных линий (paiplines), обеспечивая согласованность и повторяемость процессов.

В совокупности эти компоненты образуют единую, хорошо интегрированную среду, пригодную как для небольших команд, так и для крупных enterprise-проектов.

 

Расширяемость и экосистема Azure DevOps

 

Как и в случае с Jenkins, ценность Azure DevOps определяется не только базовыми возможностями платформы, но и ее богатой экосистемой — в частности, наличием официального маркетплейса, на котором доступно более 2600 расширений для интеграции с различными инструментами, используемыми в рамках DevOps-процессов.

Наибольшее количество расширений (свыше 1700) предназначено для инструментов Azure Pipelines. Расширения позволяют не только добавлять новые шаги в сборочные линии, но и внедрять собственные элементы управления в пользовательский интерфейс, настраивать параметры и передавать данные между компонентами.

 

Описание сборочных линий в Azure DevOps

 

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

Для выполнения отдельных задач в в сборочных линиях используются так называемые команды журналирования (logging commands) — специальный набор команд, которые интерпретируются Azure DevOps во время выполнения. Почему именно такой подход был выбран, достоверно неизвестно, но без этих команд не обойтись, например, при создании переменных в runtime или управлении ходом выполнения.

В рамках задач сборочных линий можно выполнять скрипты на различных языках: Bash, PowerShell, batch-скрипты и других, в зависимости от платформы агента.

Что касается разработки расширений для Azure DevOps, они могут быть реализованы на TypeScript или PowerShell — оба варианта официально поддерживаются платформой.

 

Структура сборочной линии: этапы, задания, шаги и задачи

 

Основные элементы описания сборочной линии в Azure DevOps — это этапы (stages), задания (jobs), шаги (steps) и задачи (tasks). Эта структура схожа с многими другими серверами сборок, основанными на YAML, например, GitLab CI.

Каждая сборочная линия описывается в YAML-файле, с использованием:

• Ресурсов (resources)

• Шаблонов (templates)

• Параметров (parameters)

• Переменных (variables)

• Условий (conditions)

• Выражений (expressions)

• Зависимостей (dependencies)

• Триггеров (triggers)

Вся выполнение происходит на агентах (agents) — машинах, где запускаются задачи сборки. Важная особенность Azure DevOps — агенты могут объединяться в пулы, что упрощает управление инфраструктурой. Кроме того, можно применять требования (demands), которые позволяют выбирать нужный агент по меткам или установленному ПО (например, наличию SonarScanner). Это особенно удобно при работе с разнородной средой.

Агенты могут запускаться как на физических или виртуальных машинах, так и в контейнерах — в зависимости от требований проекта. После прохождения всех этапов сборки на выходе формируются артефакты (artifacts) сборки — файлы, необходимые для дальнейшего развертывания и тестирования, такие как конфигурации (`.cf`), файлы шаблонов информационных баз (`.dt`) и другие, привычные для разработчиков 1С.

 

Шаблоны и параметризация сборочных линий

 

Чтобы не создавать каждый раз новое описание сборочной линии «с нуля» в виде YAML-файла, в Azure DevOps предусмотрен механизм шаблонов. Он позволяет вынести типовые сценарии в отдельные шаблоны, содержащие «внутри» всю необходимую логику отдельных этапов и заданий. После этого такой шаблон можно многократно переиспользовать, просто подключая его в нужной сборочной линии и передавая необходимые параметры.

 

 

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

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

Поддерживаются различные типы параметров:

• Простые типы — строка, число, булево значение;

• Сложные типы — объекты (по сути, структуры данных);

• Особый интерес представляет тип, представляющий собой фрагмент YAML-кода — то есть параметром может быть целый кусок описания сборочной линии, который затем подставляется в нужное место. Механизм мощный и гибкий, но в реализованном мной решении он не использовался.

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

 

Особенности препроцессора и двухэтапной обработки сборочных линий

 

Одной из особенностей Azure Pipelines является двухэтапный процесс обработки описания сборочной линии: этап компиляции и этап выполнения. Это отличает его от многих других CI/CD-систем, где описание сборочной линии интерпретируется напрямую.

На этапе компиляции используется встроенный препроцессор, который обрабатывает директивы, заключенные в двойные фигурные скобки `{{ }}`. Именно здесь выполняются условные конструкции, циклы и вычисления, позволяющие динамически формировать итоговое описание сборочной линии до ее запуска.

Разберемся с различными типами синтаксиса:

• Выражения в двойных фигурных скобках `{{ }}` обрабатываются препроцессором на этапе компиляции.

• Выражения в квадратных скобках `[ ]` вычисляются непосредственно во время выполнения сборочной линии.

• Макроподстановки в круглых скобках `$( )` используются для вставки значений переменных.

Препроцессор предоставляет мощные возможности: условные операторы (`if`), циклы (`each`) и встроенные функции (логические операции, сравнения, определение длины, форматирование строк и т.д.). Это позволяет оставлять в фактически исполняемой сборочной линии только те управляющие конструкции, которые актуальны для текущего окружения и/или значений переданных параметров.

 

 

В примере ниже, если параметр `vrunnerConfig` не пустой, препроцессор добавляет в командную строку запуска соответствующий флаг, ссылающийся на файл конфигурации vanessa-runner. Аналогично, с помощью цикла `each` можно динамически сгенерировать однотипные шаги для каждого элемента из списка — например, для разных конфигураций или сред развертывания.

 

 

Также, например, условия могут использоваться для определения требований к агентам (demands), что позволяет гибко управлять выбором сборочного узла.

 

 

 

Переменные

 

Область видимости переменных

Переменные в Azure DevOps имеют четко определенную область видимости:

• Сборочная линия (pipeline) — переменная доступна на всех этапах и заданиях.

• Этап (stage) — переменная видна только внутри одного этапа.

• Задание (job) — переменная ограничена одним заданием.

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

 

Способы обращения к переменным

Доступ к переменным можно получить несколькими способами:

• По имени: `$(MyVar)` — стандартная подстановка через `$( )`.

• По ключу, если переменная является частью структуры: `$(MyObject.key)`.

• Как к переменным среды: при этом точки в имени заменяются на нижние подчеркивания. Например, переменная `my.config.version` доступна как переменная среды `MY_CONFIG_VERSION`.

В зависимости от используемого скриптового интерпретатора (Bash, PowerShell, cmd), синтаксис обращения к переменным среды будет отличаться.

 

Предопределенные переменные

Azure DevOps предоставляет обширный набор встроенных переменных, которые содержат информацию о контексте выполнения: тип сборки, идентификатор запуска, ветка репозитория, параметры агента и многое другое. Они сгруппированы по категориям:

• Системные (`System.*`)

• Сборка (`Build.*`)

• Релиз (`Release.*`)

• Агент (`Agent.*`)

• Переменные окружения и т.д.

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

 

Управление переменными во время исполнения

У Azure Pipelines есть такая особенность, что создать переменную непосредственно во время исполнения (runtime) можно только с помощью специальных команд, так называемых logging commands. Это единственный способ динамически задать или изменить значение переменной в процессе выполнения сборочной линии.

Если переменная не была объявлена статически в YAML-файле (и не была добавлена на этапе компиляции через препроцессор), ее нельзя создать обычным скриптом. Именно для этого используется встроенный синтаксис команд, например:

```text

echo ##vso[task.setvariable variable=MyVar]MyValue

```

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

 

Встроенные шаги и возможности интеграции с другими системами

 

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

Несложно догадаться, для каких технологий в первую очередь ориентированы эти инструменты. Прежде всего, это C#, .NET и соответствующие средства сборки.

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

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

И, кстати, важный момент: тут есть шаг «Пауза». Это, пожалуй, одна из самых востребованных и ценных возможностей! :-)

 

 

 

Реализация тестирования и отчетности в сборочных линиях

 

Как я уже упоминал ранее, мы не использовали Test Plan. Вместо этого тестирование реализовано на уровне шагов сборочной линии — аналогично тому, как это делается, например, в Jenkins или GitLab CI. В рамках нашей сборочной линии такой подход оказался достаточно удобным и не вызвал необходимости использовать отдельные инструменты для управления тестами.

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

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

 

Работа с артефактами

 

Работа с артефактами — это один из моментов, в котором существенно отличаются облачное и on-premise-решения. В версии, разворачиваемой локально, функциональность по работе с артефактами значительно ограничена по сравнению с облачной.

 

 

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

 

Агенты и управление ими через требования

 

Еще один важный аспект — агенты. В целом, здесь все стандартно: агенты можно запускать как службу на хост-машине или в контейнере — как удобнее.

 

 

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

Например, можно задать требование наличия определенного флага — скажем, `SonarQube` или `SonarScanner`. Это означает, что задача будет запущена только на том агенте, где установлен и настроен соответствующий инструмент. В Jenkins и GitLab CI для этих целей используются метки агентов.

Кроме того, поддерживаются требования в формате ключ-значение, что дает еще больше гибкости — например, можно выбрать агент с определенной версией SDK, операционной системой или объемом памяти.

Агенты могут работать в облаке, на локальных машинах или в Docker-контейнерах. При этом у Azure DevOps хорошие возможности мониторинга: в отчетах можно посмотреть, какие задания выполнялись, сколько времени заняло выполнение, какова была нагрузка на агенты, что помогает эффективно управлять инфраструктурой.

 

 

 

Реализованные шаблоны сборочных линий для 1С

 

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

Было разработано четыре шаблона сборочных линий, охватывающих основные сценарии автоматизации.

Основной шаблон сборки, который представлен на схеме, включает стандартный, но эффективный набор этапов:

• подготовка тестовой базы;

• синтаксический контроль;

• анализ кода через SonarQube;

• выполнение различных видов тестов;

• формирование отчетов в Allure;

• финальная сборка конфигурации.

Шаблон синхронизации хранилищ (GitSync) — он отвечает за выгрузку изменений из хранилища конфигурации.

Шаблон сборки эталонна — подключается к эталонной базе, упаковывает ее в файл `.dt`, и сохраняет как артефакт. Далее, в основной сборочной линии, этот `.dt`-файл можно использовать при подготовке тестовой базы.

Шаблон копирования баз — основан на утилите CPDB (https://github.com/arkuznetsov/cpdb) и позволяет:

• создать резервную копию базы (рабочей или эталонной);

• восстановить ее в нужном окружении;

• переподключить к хранилищу конфигурации;

• выполнить компрессию и другие необходимые операции.

 

Инструменты и технологии, использованные в реализации

 

Среди основных инструментов, которые применялись при разработке шаблонов сборочных линий:

• 1С:Предприятие — собственно то, ради чего все затевалось :-)

• OneScript — используется для реализации скриптов автоматизации задач, которые выполняются в задачах сборочной линии;

• GitSync — инструмент для синхронизации хранилищ конфигураций 1С с репозитарием Git;

• CPDB — утилита на OneScript, предназначенная для резервного копирования и восстановления информационных баз. Позволяет автоматизировать процессы миграции и подготовки окружений;

• Vanessa-runner — инструмент для выполнения различных действий с информационными базами 1С и запуска тестов;

• Тестовые фреймворки:

  • Vanessa ADD — фреймворк для модульного и сценарного тестирования;

  • Vanessa Automation — фреймворк для сценарного (BDD) тестирования;

• Allure — инструмент анализа результатов выполнения тестов и формирования отчетов о тестировании;

• SonarQube — статический анализатор кода.

Что касается возможностей Azure DevOps, то были задействованы:

• Шаблоны сборочных линий — для стандартизации и повторного использования;

• Директивы препроцессора — для гибкой настройки сборочных линий;

• Встроенные шаги — для выполнения типовых операций;

• Расширения из маркетплейса — как готовые решения для отдельных шагов;

• Собственные расширения — разработанные под специфические задачи проекта.

Стоит отметить, что стандартных возможностей Azure DevOps оказалось недостаточно — потребовалась реализация ряда специализированных расширений (шагов).

 

Реализованные шаблоны этапов и заданий

 

В реализации шаблонов использовались как собственные расширения, так и встроенные шаги Azure Pipelines:

• Управление файлами (удаление, копирование);

• Публикация и загрузка артефактов;

• Публикация результатов тестирования для последующего анализа.

Шаблоны этапов основной сборочной линии

Были созданы шаблоны, каждый из которых соответствует отдельному этапу основной сборочной линии для 1С:

• Подготовка тестовой базы

• Базовый синтаксический контроль

• Анализ кода через SonarQube

• Запуск тестов

• Формирование отчетов в Allure

• Сборка конфигурации

Кроме того, существует обобщенный шаблон, описывающий всю сборочную линию целиком. Он объединяет все этапы в единую последовательность и позволяет быстро настроить полноценную сборочную линию для любой конфигурации 1С.

 

 

В YAML-файле описания сборочной линии достаточно указать всего несколько строк, чтобы подключить готовый шаблон, например, с именем `CI.yml`. Сам шаблон хранится во внешнем репозитории.

В Azure DevOps существует понятие ресурса (resources), ресурс позволяет ссылаться на шаблоны, расположенные как внутри текущего сервера, так и во внешних репозиториях — например, в другом проекте Azure DevOps или, например, в GitHub.

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

• Общие — такие как выбор агента, таймаут выполнения;

• Поэтапные — индивидуальные настройки для каждого шага сборочной линии (например, флаги запуска тестов или параметры SonarQube).

Здесь отдельные параметры этапов свернуты — иначе схема стала бы слишком громоздкой и трудночитаемой.

 

 

 

Таким образом, для настройки новой сборочной линии под конкретную конфигурацию 1С разработчику достаточно:

1. Подключить шаблон;

2. Передать необходимые параметры — адреса, логины, пароли, ветки и т.п.

После этого сборочная линия готова к запуску.

 

 

Важное преимущество Azure DevOps перед, например, GitLab CI — возможность хранить и использовать множество описаний сборочных линий в одном репозитарии. При этом в веб-интерфейсе можно явно указать, какую именно сборочную линию запускать, в зависимости от цели: сборка, тестирование, деплой и т.д. Это делает управление процессами более гибким и удобным.

 

 

Шаблон копирования баз данных

Этот шаблон реализует шаги создания/обновления копии информационной базы:

• резервное копирование;

• восстановление из резервной копии;

• компрессия страниц базы данных (для уменьшения занимаемого места)

• переподключение к хранилищу конфигурации.

Шаблон использует “под капотом” утилиту CPDB (Copy Database), написанную на OneScript, и позволяет клонировать эталонные, рабочие и прочие базы. Такой подход позволяет ускорить подготовку тестовых окружений.

Шаблон синхронизации хранилищ конфигурации

Шаблон обеспечивает регулярный запуск синхронизации хранилищ конфигураций с репозитарием Git для чего выполняется запуск утилиты GitSync.

При подключении шаблона передаются параметры синхронизации одним из которых является параметр `ebConnectionEndpoint`, который представляет собой ссылку на объект, хранящий настройки подключения к хранилищу 1С (адрес, логин, пароль и др.).

 

Расширения Azure DevOps

 

Управление подключениями к 1С

Расширение позволяет централизованно хранить параметры подключения к информационным базам, хранилищам конфигураций и SQL-серверам в виде так называемых service endpoints (точек подключения).

 

 

Расширение позволяет как создавать отдельные точки подключения (endpoint) для разных информационных баз, хранилищ и баз данных, так и объединять все настройки в одну универсальную точку подключения. При этом чувствительные данные, такие как пароли, автоматически скрываются и защищаются.

 

 

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

Ниже в примере в сборочную линию в качестве значения параметра `endpoint` передается объект, предварительно созданный в веб-интерфейсе Azure DevOps, содержащий данные для подключения к хранилищу 1С (адрес, логин, пароль и т.д.).

 

 

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

Интеграция с Allure

Для отображения результатов тестирования был выбран Allure по двум причинам. Во-первых, у Allure богатые возможности по визуализации результатов тестирования. Во-вторых, он уже хорошо знаком командам, работающим с 1С и строящим сборочные линии.

 

 

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

Выполнение проверки кода в SonarQube

Изначально для интеграции с SonarQube была попытка использовать официальное расширение из маркетплейса, оно в целом работоспособно, но заточено в первую очередь под .NET-проекты и разбивает процесс на три этапа: до сборки, после тестов и публикацию результатов.

В результате было разработано собственное расширение, которое выполняет анализ кода за один шаг, в привычной и понятной для большинства разработчиков (1С) манере.

 

 

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

Все необходимое для подключения и выполнения анализа настраивается элементарно: указывается адрес сервера SonarQube, токен аутентификации и имя соединения.

 

Расширение для запуска скриптов на OneScript

 

PowerShell — не самая любимая технология у многих разработчиков 1С, в то время как OneScript давно стал привычным инструментом. Чтобы максимально использовать его возможности в Azure DevOps, было разработано специальное расширение, позволяющее запускать скрипты на OneScript непосредственно в сборочных линиях. Это стало решением для тех случаев, когда стандартных шагов или встроенных команд не хватает.

 

 

Расширение полностью интегрировано в систему: поддерживаются все возможности Azure Pipelines, включая макроподстановки, вычисление переменных и работу с окружением. Например, можно использовать синтаксис вроде `##vso[task.setvariable]` для создания переменных. Особенно приятно было убедиться, что даже сложные конструкции, такие как объявление и присвоение значения переменной через `##`, корректно обрабатываются.

В приведенном примере показано, как с помощью OneScript извлекается номер версии конфигурации.

Возможности расширения:

• Выполнение inline-скрипта, переданного через параметр `script`.

• Запуск скрипта из файла, расположенного в репозитории — удобно для сложных или переиспользуемых сценариев.

• Управление пакетами opm: поддержка команд `opm install` и `opm update` для установки зависимостей.

• Запуск установленных приложений — возможность вызывать любые приложения, добавленные через OPM (например, `vanessa-automation`, `runner` и др.).

Последняя функция, хоть и не обязательна (аналог можно реализовать через PowerShell или batch-файлы), была добавлена для удобства и завершенности. Она позволяет держать весь процесс в рамках OneScript, не переключаясь на другие языки. Такой подход не только упрощает поддержку, но и выглядит эстетичнее — все на одном, привычном стеке.

 

Итоги реализации и перспективы развития

 

В итоге мы научились запускать полноценные сборочные линии для 1С в среде Azure DevOps — платформе, которая уже активно используется в компаниях, где доминирует стек Microsoft и .NET-разработчики. Теперь и мы, 1С-разработчики, можем уверенно входить в эту экосистему и, можно сказать, слегка «напугать» коллег-C#-программистов: «А теперь у вас здесь будет и 1С!»

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

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

Важно и то, что YAML-синтаксис, используемый в Azure Pipelines, является стандартом для большинства современных систем CI/CD (за исключением, пожалуй, Jenkins). Это дает возможность в будущем адаптировать наработанные шаблоны для других платформ, например, GitLab CI.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.