Миграция сборки yaml и выпуск конвейеров classi c в многоступенчатый yaml - PullRequest
Новая
       83

Миграция сборки yaml и выпуск конвейеров classi c в многоступенчатый yaml

2 голосов
/ 11 марта 2020

Я планирую перенести мои старые конвейеры CI / CD, которые представляют собой смесь новых конвейеров YAML для сборок и конвейеров Releases на основе пользовательского интерфейса 'classi c', в многоступенчатый файл YAML на основе среды. , но я изо всех сил пытаюсь найти документы / примеры, которые следуют вместе с тем, что мы делаем в настоящее время.

Обычно существует три среды: Test, UAT и Production.

Все они основаны на AKS, и в настоящий момент сборка, создающая контейнер (ы) docker, будет как часть своего вывода хранить файл DeployService.yml, который используется конвейером выпуска для обновления каждой среды (путем изменение тега изображения и некоторых переменных среды) перед запуском kubectl apply -f DeployService.yml.

В настоящее время у меня есть несколько проектов, которые следуют этому шаблону: 

╔══════════════════════════╦══════════════════╦══════════════╦══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╗
║           Name           ║     Purpose      ║     Type     ║                                                                     Description                                                                      ║
╠══════════════════════════╬══════════════════╬══════════════╬══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╣
║ {project-name}.ci.yml    ║ CI build         ║ YAML-based   ║ Triggered on pull-requests. Builds, run tests, etc. The only output is test results and success/ failure in Azure DevOps.                            ║
║ {project-name}.cd.yml    ║ CD build         ║ YAML-based   ║ Builds the output upon successful PR into master. This is more often than not a docker container.                                                    ║
║ {project-name} - Release ║ Release Pipeline ║ 'Classic' UI ║ Release pipeline, triggered by {project-name}.cd.yml success and deploys into the Test environment. From there it's promotion to UAT and Production. ║
╚══════════════════════════╩══════════════════╩══════════════╩══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╝

Я хотел бы переместить все они в новый многоступенчатый конвейер сборки и выпуска YAML с использованием одного файла.

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

На данный момент новая сборка может:

  • Выполнить сборку, которая создает и толкает контейнер docker.
  • Запустите релиз, который выдвигается в среду Test.

В рамках этого шаблона в папке репозитория создается папка manifests, содержащая deployment.yml и service.yml. Он также создал среду, которая подключена к нашему Test AKS-кластеру.

Итак, мои вопросы таковы:

  1. Учитывая, что deployment.yml должен содержать переменные среды, определяющие c переменные (подумайте ASPNETCORE_ENVIRONMENT), как мне предоставить эти дополнительные среды, определяющие c переменных для среды выпуска?
  2. Могу ли я воссоздать тот же конвейер выпуска в стиле продвижения, который был у меня с использованием Classi c UI релизы?
  3. Будет ли сборка CI вписываться в этот процесс вообще? Или я должен оставить его в отдельном файле?
  4. Учитывая, что существует множество проектов, которые следуют этому шаблону, и по большей части они все делают одно и то же, но создают контейнеры, специфицирующие проекты c, есть ли возможность повторного использования между репозиториями?

1 Ответ

1 голос
/ 12 марта 2020

1, предоставьте дополнительные переменные среды c для переменных для deploy.yml.

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

2, Вы можете создать тот же стиль продвижения, что и в Classi c UI.

Вы можете определить зависимости и условия для управления запуском этапа на основе состояния запуска предыдущего этапа. Для примера ниже. 

stages:
- stage: A

# stage B runs if A fails
- stage: B
  condition: failed()

# stage C runs if B succeeds
- stage: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')

Вы также можете добавить Одобрения и Проверки для ваших этапов. Пожалуйста, проверьте документ Определите утверждения и проверки

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

3, я предлагаю вам оставить сборку CI в отдельном файле. Если он находится в одном и том же файле yaml, то все последующие сборки и этапы создания компакт-диска будут запускаться по запросу извлечения.

4, Шаблоны позволят вам определить повторно используемый контент, logi c и параметры. Вы можете поместить задачи / задания, которые используются многими проектами, в файл yaml шаблона. Пожалуйста, проверьте здесь для получения дополнительной информации о шаблоне yaml.

...