Внедряване на Gates в Azure YAML тръбопроводи

Виждал съм и съм използвал Azure Release Pipelines.

Търсим да използваме YAML базирани конвейери, тъй като е лесно да се контролира версията в Git. Има ли някакъв начин да се разделят тръбопроводите на етапи и всеки етап да има одобрение и ръчно задействане на следващия етап.


person forvaidya    schedule 07.05.2020    source източник
comment
Здравей, @forvaidya, тъй като отговорът по-долу на Krzysztof Madej ви помага. Можете да го приемете, ако смятате, че отговаря на изискванията   -  person Levi Lu-MSFT    schedule 21.05.2020
comment
@forvaidya можеш ли да отбележиш отговора ми като отговор?   -  person Krzysztof Madej    schedule 04.11.2020


Отговори (1)


В YAML работи по различен начин. За да използвате одобрения и проверка, първо трябва да дефинирате среда. След като имате среда, можете да дефинирате approvals and checks.

въведете описание на изображението тук

Важно е

Одобренията и другите проверки не са дефинирани във файла yaml. Потребителите, които променят yaml файла на тръбопровода, не могат да променят проверките, извършени преди началото на етап. Администраторите на ресурси управляват проверките с помощта на уеб интерфейса на Azure Pipelines.

След това в заданието за внедряване можете да изберете среда:

jobs:
- deployment: string   # name of the deployment job, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  pool:                # see pool schema
    name: string
    demands: string | [ string ]
  dependsOn: string 
  condition: string 
  continueOnError: boolean                # 'true' if future jobs should run even if this job fails; defaults to 'false'
  container: containerReference # container to run this job inside
  services: { string: string | container } # container resources to run as a service container
  timeoutInMinutes: nonEmptyString        # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: nonEmptyString  # how much time to give 'run always even if cancelled tasks' before killing them
  variables: { string: string } | [ variable | variableReference ]  
  environment: string  # target environment name and optionally a resource-name to record the deployment history; format: <environment-name>.<resource-name>
  strategy: [ deployment strategy ] # see deployment strategy schema

Можете също да проверите тази тема в github

Няма планове за добавяне на одобрения в YAML. Ние обаче планираме да поддържаме конфигуриране на одобрения на различни ресурси, например връзки към услуги, групи променливи, пулове агенти и т.н.

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

person Krzysztof Madej    schedule 07.05.2020
comment
Благодаря, това помага. Това означава, че администрирането на Environment и YAML файловете е различна отговорност и механизъм за сигурност. Въпреки че нямам права за промяна на средата в нашата корпоративна среда, ще го пробвам в пробен акаунт - person forvaidya; 07.05.2020