O240 Deployment Guide

Document status	35 - Reviewed

A Deployment Guide must describe how a solution is deployed and thus how it is moved from a development environment to a test environment and on to a production environment. To ensure an effective deployment process, the description should contain all details that are worth knowing about pipelines and differences between the environments that are used in the project.

Solution components

The overall solution and its' components are described further in System Landscape, and will therefore not be described further in this document.

Components of the deployment pipeline

The following list are the major components of the pipelines implemented in Azure DevOps.

Pipeline Templates

To ensure consistency and reusability across multiple pipelines, we have created pipeline templates for all pipelines.

These templates are stored in the '.azuredevops/templates' directory and can be referenced in any pipeline YAML file.

Pull Request Pipelines - Continously Integration (CI)

The Pull Request (PR) pipelines are responsible for building the solution components, running unit tests, and running scans.

• pr-bicep-psrules-analysis: Validates Bicep files using PS.Rules
• pr-build-validation: Builds the Docker images and runs unit- and system integration tests for all services
• pr-sonarqube-analysis: Runs static code analysis using SonarQube Scan from SonarCloud. The code has to score above a strict level to pass the Quality Gate.

Once a PR is created to merge to a Release branch, the PR pipelines are automatically triggered to run and ensure code changes do not introduce any issues.

A PR cannot be completed until the CI pipelines have successfully run and passed all checks.

Maintenance Pipelines

Maintenance pipelines are used for various maintenance tasks, but is currently limited to 1 pipeline:

• vm-start-schedule: Starts and stops Virtual Machines based on a defined schedule to save costs during non-working hours.

Release Pipelines (CD)

We have the following release pipelines:

• infrastructure-prerequisites: Deploys any prerequisites needed for the infrastructure deployment (rarely used)

  • Entra ID groups (infra + app)
  • App Registrations
  • Role Assignments
  • Key Vault and secrets
  • Storage Account for VM backups and scripts

• infrastructure-deployment: Deploys the main Bicep infrastructure code to the target environment (daily / often)

  • Deploys all other Infrastructure components such as Virtual Machines, Disks, Container Apps, Networking, Service Bus, Application Insights, Log Analytics, App Configuration, Managed Identities, DNS Integration and much more.

• database-configurations: Deploys the database changes to the target environment (rarely used)

  • Creates Database related keyvault secrets for app configurations
  • Runs initial database setup scripts to create Database users, roles, permissions, tablespaces, schemas and various other DB configurations

• database-migrations: Runs database migrations to update the database schema as needed (daily / often)

  • Runs Entity Framework Core migrations to contiously update the database schema

• application-deployment: Deploys the application code to the target environment (daily / often)

  • Builds and pushes Docker images to the Container Registry
  • Deploys Container Apps with the latest Docker images and updated configurations
  • Runs Container App health checks to ensure the application is running as expected

Automatic Triggering of Pipelines

All release pipelines have automatic triggers, which means they are automatically triggered when changes are merged to the respective release branches.

The triggers do not mean the pipelines will automatically deploy to an environment, as approvals and gates are configured to control the deployment flow, but then the triggers will start the pipeline process and prepare the deployment.

Besides automatic triggers, all release pipelines can also be manually triggered as needed.

Approvals and Checks

As part of the release pipelines, we have configured approvals and gates to ensure proper review and validation before deploying to an environment.

• Azure DevOps Environments: Each environment is configured as an Azure DevOps Environment, which allows us to set up approvals and checks for deployments to that environment.
• Approvals: Each environment has specific approvals groups that can approve deployments to that environment
• Gates: All pipelines have dependencies to the environments, such as a higher level environment cannot be deployed to unless the lower level environment(s) has been successfully deployed (e.g. Prod cannot be deloyed to unless Preprod has been successfully deployed to)
• Branch Control: Each Azure DevOps Environment has branch control configured to ensure only specific branches can deploy to that environment (e.g. release/3.1 can only deploy to a specific customer environment)
• Exclusive Locks: Each Azure DevOps Environment has exclusive locks enabled to ensure only one deployment can occur at a time to prevent conflicts.
• PR Reviews: All code changes must go through a Pull Request (PR) process, which includes mandatory code reviews and approvals from members in a specific Azure DevOps Group and successful completion of the PR pipelines before merging to a release branch.

Vulnerability Dependency Scanning

The release branches have additional scans and checks configured to ensure code quality and security:

• Software security scanner for dependencies and vulnerabilities using Azure DevOps Advanced Security

Environment Structure and Deployment Flow

At this perspective an environment is also considered an Azure Subscription.

So each environment, e.g. test is also an isolated Azure Subscription.

There is a hard gate between each environment, meaning that code must be promoted from one environment to the next. For the customer environments all promotions are manual, while the internal environments can be automatic.

Deployment Flow for a new environment

When a new environment is created, the deployment pipeline flow is as follows:

1. infrastructure-prerequisites
2. infrastructure-deployment
3. database-configurations
4. database-migrations
5. application-deployment

Internal Environments

The following environments are considered internal and are for creating, testing and adding new features before they are promoted to customer environments.

Environment Name	Azure Subscription Name	Data	DataHub connection	Stability
test	EnergyConnect-test	mock	false	unstable
qa	EnergyConnect-qa	mock	true, 939, preprod	stable

In daily operations the environments are referenced as: internal test and internal qa.