The booking portal of Nordlicht Reisen GmbH, a fictional travel agency, is rolled out to three environments: test, acceptance, production. Only what comes from the main branch, what a responsible person has approved and what doesn't run at the same time as a second rollout may go into production. The pipeline authors should not be able to strike these rules out of the YAML file, whether by mistake or on purpose. That is the skill of this lesson: setting up checks and approvals with YAML-based environments, in both worlds.

Prior knowledge: That a rollout to an environment waits for an approval between stages, and how revisions roll back, is taught in K3, lesson 3.7.6. Stages and conditions are in lesson 4.3, gates as a design in lesson 4.6. What is new here is completeness: all checks of Azure Pipelines in detail, their order, the rules for your own checks, the roles and the counterparts in GitHub.

Not run against Azure, GitHub or Azure DevOps; from the reference of Microsoft and GitHub: All commands, YAML files and menu paths of this lesson come from the documentation or are derived from it; they were not run in this course.

Environments in Azure Pipelines

An environment is a group of resources that a pipeline can deploy to, and stands for a logical target such as development, test, acceptance or production. As resources it currently supports, according to Microsoft, Kubernetes and virtual machines; an empty environment also makes sense, as an anchor for the history and for checks. Microsoft names four benefits:

  • Deployment history: Pipeline and run are recorded per environment and resource; several pipelines that change the same target are visible in one history.
  • Traceability of commits and work items: You see which commits and which work items are new in the environment (lesson 1.1).
  • State of the resources: whether the application runs in the desired state.
  • Security: You decide who may use the environment and which pipelines may use it.

Environments exist only in YAML pipelines; for classic pipelines, Microsoft names deployment groups as a similar facility.

Targeting in the deployment job

A deployment job (lesson 4.3) names the environment with environment:

YAML
- stage: Produktion
  jobs:
    - deployment: Web
      environment: buchungsportal-prod
      strategy:
        runOnce:
          deploy:
            steps:
              - script: echo Auslieferung

The long form selects a resource of the environment so that history and connection data go to the resource:

YAML
environment:
  name: buchungsportal-prod
  resourceName: myVM
  resourceType: virtualMachine

With environment: 'buchungsportal-prod.bookings' (environment, dot, resource), the steps inherit the connection of the resource, for example of a Kubernetes namespace. With machines as the resource you need no pool: The steps run on the machine.

Creating: Either in the Azure DevOps portal (Pipelines, Environments, Create environment), or automatically if the YAML file names an environment that doesn't exist. That works only if Azure Pipelines knows the creator, that is, when creating the pipeline in the wizard or when saving in the web editor. Whoever changes the file in an external editor and triggers a run gets an error, because it is unknown who should become administrator of the new environment. Earlier, all contributors became administrators instead; Microsoft turned that off so that nobody changes the rights of the others. For the names: Runtime parameters don't work in environment names, because they are expanded only at run time; use variables or templateContext.

Roles and pipeline permissions

The user permissions know four roles:

Role May
Creator global role: create environments in the project; needed if a YAML run should create the environment; contributors are members by default
Reader view the environment
User use the environment when writing or changing YAML pipelines
Administrator permissions, create, manage, view, use; the creators are administrators by default; they can open the environment to all pipelines

Approvals and checks are managed, according to Microsoft, by the roles Creator, Administrator and User, not by the role Reader. Permissions can be set per environment under Security, also inherited and overridden. In addition there are Pipeline permissions: By default, every pipeline may use an environment ("open access"); with Restrict permission you narrow that and then allow individual pipelines with +. For production environments, this is the basic setting you choose.