Microtec DevOps

Appearance

Pipeline Orchestrators ​

Microtec ERP uses several pipeline orchestrators that cover the full deployment lifecycle — from feature development to production release and environment teardown. All pipeline entry points live under Devops/azure/pipelines/container-backend/ and extend orchestrators in Devops/azure/orchestrators/.

Pipeline Entry Points (pipelines/container-backend/) ​

FilePurposeTrigger
all-repos-pipeline.ymlAll 13 services from all reposManual only
platforms-pipeline.ymlPlatforms repo services (7)Branch push
hr-pipeline.ymlHR Personnel serviceBranch push
keycloak-pipeline.ymlKeycloak identity serviceBranch push
infrastructure-pipeline.ymlInfrastructureServices (Attachment, Notification, Template)Branch push
fast-deploy-pipeline.ymlManual fast deploy (single service, no infra)Manual only
production-release-pipeline.ymlProduction promotionManual only
deprovision-pipeline.ymlTear down an environmentManual only
workflow-pipeline.ymlWorkflowDesigner serviceBranch push

Agent Pool ​

All backend container pipelines use the self-hosted agent pool:

yaml
pool:
  name: 'MIC-EG-AGENT'

Self-Hosted Only

Backend pipelines require Docker, the .NET SDK, and ACR authentication — all pre-configured on the MIC-EG-AGENT pool. Microsoft-hosted ubuntu-latest agents are only used for frontend Angular builds (public npm access).

Pipeline Template Structure ​

Pipelines are composed from reusable templates organized in three layers:

Devops/azure/templates/
├── stages/                             # Stage-level templates
│   ├── initialize.stage.yml           # Parse config, set environment variables
│   ├── build-docker.stage.yml         # Docker build + ACR push
│   ├── deploy-container.stage.yml     # Update CAE revisions
│   ├── provision-infra.stage.yml      # Bicep infrastructure deployment
│   ├── fast-deploy.stage.yml          # Fast path: single service, no infra
│   ├── notify.stage.yml               # Teams/email notifications
│   ├── approval.stage.yml             # Manual approval gate
│   └── [others]
├── jobs/
│   ├── detect-container-services.job.yml   # Detect changed services
│   └── detect-frontend-apps.job.yml        # Detect changed frontend apps
└── steps/
    ├── backend/                        # Backend-specific step templates
    ├── frontend/                       # Frontend step templates
    ├── common/                         # Shared steps (checkout, auth, etc.)
    └── [others]

Orchestrator 1: Full Container Deployment ​

Purpose: Full end-to-end backend deployment. Runs infrastructure changes, builds Docker images, deploys to Container Apps.

Entry points: platforms-pipeline.yml, hr-pipeline.yml, infrastructure-pipeline.yml, etc.

Typical duration: 20–30 minutes

Stages:

StageTemplate UsedDescription
Initializetemplates/stages/initialize.stage.ymlReads services-config.json, sets pipeline variables
Buildtemplates/stages/build-docker.stage.ymlBuilds only services with changed images
Provision Infratemplates/stages/provision-infra.stage.ymlOptional idempotent Bicep deployment
Approvaltemplates/stages/approval.stage.ymlManual gate for non-dev environments
Deploytemplates/stages/deploy-container.stage.ymlUpdates container app revisions
Notifytemplates/stages/notify.stage.ymlSends Teams notification

When to use:

  • New feature branch merged to any environment branch
  • Infrastructure changes (new service, scaling config, VNet changes)
  • Environment variable or secret changes
  • Any change to services-config.json
  • Keycloak updates

Pipeline parameters (common across entry points):

yaml
parameters:
  - name: targetEnvironment
    type: string
    default: dev
    values: [dev, stage, preprod, uat]   # production via production-release-pipeline.yml

  - name: deployMode
    type: string
    default: manual
    values: [manual, branch, force-all]

  - name: provisionInfrastructure
    type: boolean
    default: false

  - name: skipApproval
    type: boolean
    default: false

  - name: serviceToggles
    type: object    # Per-service boolean toggles (svc_gatewayApi, svc_appsportalApi, etc.)

Branch triggers (from infrastructure-pipeline.yml example):

yaml
trigger:
  branches:
    include:
      - main
      - master
      - develop
      - Stage
      - Production
      - Sprint*

Orchestrator 2: Fast Deploy ​

Purpose: Image-only deployment. Skips infrastructure provisioning. For hotfixes where only the application code changed.

Entry point: pipelines/container-backend/fast-deploy-pipeline.yml

Stage template: templates/stages/fast-deploy.stage.yml

Typical duration: 3–8 minutes

Trigger: Manual trigger only (no automatic branch trigger).

Parameters:

yaml
parameters:
  - name: targetEnvironment
    type: string
    default: dev
    values: [dev, stage, preprod, uat]

  - name: deployMode
    type: string
    default: manual
    values: [manual, force-all]

  - name: serviceToggles
    type: object    # Boolean toggles per service (same pattern as full deploy)

  - name: skipApproval
    type: boolean
    default: false

serviceToggles, not serviceName

The fast deploy pipeline uses serviceToggles (the same boolean-per-service pattern as the full deploy), not a single serviceName string. The stage template (fast-deploy.stage.yml) runs az containerapp update directly without running Bicep.

When to use: See Fast Deploy Path for full decision guide.

Orchestrator 3: Production Release ​

Purpose: Production deployment with manual approval gates and extended validation. Wraps the full container deployment orchestrator with pre-flight checks and human approval steps.

Entry point: pipelines/container-backend/production-release-pipeline.yml

Typical duration: 40–60 minutes (including approval wait time)

Stages:

Orchestrator 4: Deprovision ​

Purpose: Tears down all resources in a specified environment. Used for cost savings or cleanup.

Entry point: pipelines/container-backend/deprovision-pipeline.yml

Typical duration: 10–20 minutes

Destructive Operation

This pipeline permanently deletes Azure resources. SQL databases, Key Vault secrets (after 90-day soft-delete period), and container images are not automatically backed up. Ensure all data is backed up before running.

Variable Groups ​

Each environment has a corresponding variable group in Azure DevOps Library:

Variable GroupScope
container-backend-sharedShared across all environments (minimal; NuGet uses System.AccessToken)
container-backend-secrets-devDev environment secrets
container-backend-secrets-stageStage environment secrets
container-backend-secrets-preprodPreprod environment secrets
container-backend-secrets-uatUAT environment secrets
container-backend-secrets-productionProduction environment secrets

$(System.AccessToken)

The NuGet private feed uses the built-in $(System.AccessToken) pipeline identity for authentication. This token is automatically provisioned by Azure DevOps and never expires. No manual PAT management required.

Service Connection ​

The pipelines use the Azure service connection named fontEndPrincipalConnection (note: the typo "font" is the actual name in Azure DevOps — do not "fix" it).

Internal Documentation — Microtec Platform Team