Skip to content

Latest commit

 

History

History
187 lines (113 loc) · 6.29 KB

README.md

File metadata and controls

187 lines (113 loc) · 6.29 KB

CI/CD

Azure CLI DevOps extension provided commands are used underneath for bootstrapping the Azure DevOps project and the pipelines.

The CLI has its limitations (e.g. defining approval conditions in environments) thus after IAC some manual steps are suggested as documented further below.

Prerequisites

Azure resources are assumed already created with Bicep.

Below instructions assume that the source repository is hosted in GitHub.

For fetching the git repo in Azure Pipelines, preferable configure the Azure Pipelines GitHub app and grant repository access to your fork in the GitHub app configuration:

Azure Pipelines app on GitHub

Otherwise, create a GitHub personal access token and select scope as repo in the GitHub personal access token configuration:

Creating GitHub personal access token

For each pipeline, you still get recommendations to switch to GitHub app later:

Azure Pipelines app on Azure DevOps

Setup tools

Login and install the Azure CLI DevOps extension:

az login
az extension add --name azure-devops --upgrade --yes

Azure DevOps IAC

Each of the pipelines will have its own service connections for GitHub, Azure Resource Manager and Azure Container Registry.

One service connection is are backed by one service principal which are created by the scripts per pipeline as following:

Infra:

  • GitHub
  • AzureRm (the SP will have subscription Contributor)

Non-productions:

  • GitHub
  • AzureRm (the SP will have Contributor in the stg rg)
  • Registry (the SP will AcrPush in the stg ACR)

Production:

  • GitHub
  • AzureRm (the SP will have Contributor in the prod rg)
  • Registry (the SP will have AcrPush in prod ACR)

Copy infra.env.example to infra.env, configure variables and create project:

./create_azdo_project

Copy stg.env from the template, configure variables and create the pipeline:

./create_azdo_pipeline stg.env

Copy pr.env from the template, configure variables and create the pipeline:

./create_azdo_pipeline pr.env

Copy prod.env from the template, configure variables and create the pipeline:

./create_azdo_pipeline prod.env

Role User Access Administrator is added to the infra SP in stg's and prod's resource groups for bicep/deploy to assign the managed identity of the App Service as Key Vault Reader and a service principal to ACR with role AcrPull.

Infra SP's required Azure AD permissions

You may also have to assign Azure AD role Cloud application administrators to the infra SP. This is for bicep/deploy to run the Azure AD related commands for creating service principals and App Service AAD app successfully.

Whether this is required or not depends on your tenant's permissions for creating/updating Azure AD resources as non-administrator. Assigning Azure AD administrator roles to others requires User Administrator role in the tenant.

Pipeline to deploy API to APIM (optional)

If you have existing Azure API Management instance(s) and wish to import or update the API there (based on APIs openapi.yaml), copy apim.env.example to apim.stg.env and apim.prod.env and configure the variables in the files.

Here, the same api-to-apim pipeline is used for both environments (~ stages).

To create API deploy pipeline and assign Api Management Service Contributor:

./create_azdo_api2apim apim.stg.env

To do the same for the production-dedicated API Management service:

./create_azdo_api2apim apim.prod.env

Manual steps

The below are not supported by Azure CLI DevOps extension and although they can be done via REST API, they are one-off operations and are fastest done via Azure DevOps web GUI.

Permit service connections

Because service principals per environment, service connections are not granted access for all pipelines.

Also, when any of the pipelines is ran first time (or the service connections are recreated by the IAC), the project administrator must approve the pipeline to use the new service connection.

Set pipeline triggers

For security, it is always recommeded to override the triggers defined in azure-pipelines YAML files.

Do so for each pipeline in the pipeline settings as explained below.

staging

Continuous integration: branch filters -> if include main

Override pipeline triggers for main

Pull reqest validation: branch filters -> if include main

  • Require team member's comment before build
    • Only on pull request from non-team members

Override pipeline triggers for PRs

production

  • Continuous integration: branch filters -> if include main
  • Pull reqest validation: disabled

Environments: Branch controls

These environments are created:

Azure DevOps environments

For 'staging', and 'production' environments, go to 'approvals and checks' and create a branch control check with allowed branches as refs/heads/main.

Configure branch controls for environment

Environments: Manual approvals

If no approval conditions are defined in the Azure DevOps environments, the pipelines won't prompt anything which is wanted unless goind to production.

Thus for production configure:

  • require approval (if set to a group -> one member of the group must approve)
  • timeout e.g. 1h

Process fine-tuning

If using Slack and the Azure DevOps Slack app, the pending approvals are notified on the channel and can be approved or denied there with a button.

  • Create other service hooks e.g. teams notifications, etc.

  • Pipelines Settings: Change days to keep runs 30 -> 365 (and PRs 10 -> 30)

Increase pipeline run retention period

  • If only using Azure DevOps for pipelines, you may disable unused services:

Disable unused project services