Блог

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

1. Это выпуски Azure DevOps.
2. Приложение содержит более одного артефакта, который должен быть доставлен как единое целое. Дистрибутив приложения, его модули и некоторая конфигурация для серверов, которые напрямую не связаны с приложением, и, конечно, сценарии автоматизации (которые являются версионными). Все они имеют свой собственный процесс сборки и могут иметь отдельные версии.
3. Все эти компоненты (приложение, отдельная конфигурация сервера, автоматизация) поставляются как одна версия продукта. Однако они могут иметь разные версии, например: 12.2.1 (приложение), 12.2.3 (сервер), 12.2.1 (автоматизация).

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

1. Конвейеры выпуска и 3 артефакта: хорошо, есть 3 артефакта, и пользователь должен указать все 3 версии вручную во время создания — довольно высокий риск неправильного нажатия. К сожалению, их 10… 10 умножьте 3 = 30 раз, чтобы сделать ошибку.
2. Конвейер выпуска и 1 артефакт (приложение): рассмотрите только одну версию приложения и автоматически получите сценарии автоматизации и конфигурацию из feed, используя версию приложения. Может работать, но нет возможности наблюдать, какие артефакты будут использоваться, нет способа понизить рейтинг, единственная последняя версия артефактов (12.2.3. *).
3. Укажите версию в группе переменных, подключенных к этапу (среды). Можно легко допустить ошибку, поскольку release использует версию baken группы переменных. Если вы обновите VG, но не создадите выпуск — это будет эпический сбой. Более того, нет представления о том, что он собирается устанавливать / обновлять и т. Д.

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

Вот как это работает для меня с помощью этого простого подхода:-

• Единый конвейер сборки с множеством заданий агента, где каждое представляет артефакт.
  • Итак, здесь вы будете публиковать разные артефакты в отдельных папках и автоматически увеличивать версии «При необходимости», используя скрипт для каждого, и в конце все будут находиться под одним и тем же buildId.
  • Другой вариант, если разделение не требуется, чтобы все они находились под одним и тем же заданием агента.
• Единый конвейер выпуска, связанный с этим большим вложенным артефактом, который будет выполнять развертывание.
  • Здесь также, если требуется разделение, могут быть многоступенчатые или многоагентные задания, как и раньше.
• Увеличение версий либо будет происходить вручную при фиксации, либо сценарии будут автоматически увеличивать каждую сборку.
  • Я бы предпочел первое, поскольку второе не указывает на какие-либо изменения.
  • Вероятность того, что разработчик забудет обновить версию, будет такой же, как если разработчик внесет ошибку, чтобы ее можно было исправить позже.

Затем в конце у вас есть один выпуск => Одна сборка => Много версий => Фиксация.