Skip to content

DevOps & CI/CD

Version History

Version Date Description/Updates
1.0 2026-03-25 Initial version

Introduction

Continuous Integration and Continuous Delivery/Deployment improve software delivery through automation, repeatability, and fast feedback. At DHI, CI/CD guidance must stay practical: make the required baseline clear, keep recommended patterns easy to adopt, and describe advanced options only where they add value.

Contacts
Guidelines Owner Sam Johnson
Task force Sam Johnson; Kristian Thage; Jesper Grooss; Jaroslav Kopriva; Karthik Balachandran; Senthil Kumar Shanmugasundaram; Franz Thomsen
Stakeholders Dr. Milan Pelletier; Grzegorz Kula; Henrik Andersson; Marie Lund Larsen
Approver(s) Architecture Board

Roles to Apply

  • Architects
  • Backend developers
  • Frontend developers
  • Infrastructure/DevOps Engineers
  • Product Owners / Project Managers

Enforcement Levels

Enforcement levels follow the Development Standards Overview. The overall guideline is DHI good practice, with individual controls marked as Mandatory, Expected, Important, or DHI good practice.

Section Enforcement Level When/what
CI baseline Mandatory For every actively maintained repository
Quality gates and approvals Expected When protecting branches and release environments
Writing pipelines Important When creating or refactoring YAML pipelines
Versioning and release identifiers Expected When producing releasable artifacts
Artifact management Expected When publishing packages, containers, or installers
Desktop applications and installers Important When shipping desktop software
Continuous delivery and deployment Important When defining release flow
Deployment strategy selection Important When planning production rollout
Infrastructure as Code integration Important When environments or cloud resources change with releases
Secrets and credentials management Mandatory When configuring pipelines and environments
AI assistance and starter templates DHI good practice When creating new CI/CD assets

CI baseline

Mandatory

  • Every actively maintained repository must have a repeatable build pipeline in version control.
  • Pull requests to protected branches must run automated validation before merge.
  • Pipelines must produce versioned build outputs or explicitly verify why the repository has no releasable artifact.
  • Secrets must not be hard-coded in repositories, pipeline YAML, or ad-hoc scripts.

Expected

  • Pipeline definitions, reusable workflow files, and release scripts must be reviewed like application code.

Important

  • Define pipelines as code in version control for new work. Legacy or classic build configurations should only remain temporarily and with a migration plan.
  • Make the same build/test/package commands runnable locally or through checked-in scripts, so CI stays easy to understand and troubleshoot.
  • Run relevant automated tests, static analysis, and security scanning as part of the normal CI path.

DHI good practice

  • Measure build duration, queue time, and flaky steps so pipeline quality can improve over time.
  • Reuse shared pipeline components instead of copying near-identical jobs across repositories.

Quality gates and approvals

Mandatory

  • Require pull request review before merging to protected branches.
  • Require successful CI status checks before merge.
  • Require clear ownership for critical repositories or areas with significant business impact.

Expected

  • Define baseline quality gates for tests, static analysis, and security findings, with thresholds appropriate to the repository type.
  • Use environment-based approvals for production promotions and other high-risk environments.

Important

  • Ensure the approver is not the same person who prepared the change where separation of duties is needed.

DHI good practice

  • Enforce “no coverage decrease” on pull requests when a fixed threshold is too blunt.
  • Use reusable approval policies and CODEOWNERS to reduce per-repository drift.

Writing pipelines

Pipeline YAML should stay focused on orchestration, not on embedding large amounts of application-specific logic.

Mandatory

  • Keep application-specific build logic in repository scripts, build tools, or make targets rather than inline pipeline shell blocks.
  • Separate build, test, package, and deploy responsibilities so failures are easier to understand.
  • Keep environment-specific values in variables, parameters, or environment configuration rather than duplicated job definitions.

Important

  • Prefer small composable jobs and stages over deeply nested conditional logic.
  • Prefer reusable workflows/templates/actions for repeated patterns.
  • Keep names explicit: stages and jobs should describe intent such as build, test, package, deploy-staging, and deploy-production.

Detailed authoring guidance is available in Writing Pipelines.

Versioning and release identifiers

Mandatory

  • Every releasable artifact must have a unique version that is traceable to a source revision and pipeline run.
  • Released artifacts must be immutable: do not rebuild a different binary, container, or package under the same released version.
  • The tested artifact must be the artifact promoted to the next environment.

Expected

  • Use Semantic Versioning for libraries, packages, APIs, and services unless the product already has an agreed alternative versioning scheme.
  • Tag source control for production releases and keep release notes tied to those tags.

Important

DHI good practice

  • Add provenance metadata such as commit SHA, build number, SBOM location, and changelog link to release records.

Artifact management

Build outputs should be published to a managed artifact repository or registry to support traceability, retention, repeatable deployment, and rollback.

Artifact type Typical examples Minimum expectations
Packages NuGet, npm, Python wheels Immutable version, repository metadata, source revision, retained build logs
Containers OCI/Docker images Immutable digest, versioned tag, recorded base image, registry retention policy
Desktop deliverables MSI, MSIX, EXE, ZIP Product version, checksum or signing status where applicable, release notes, retained installer package
Deployment bundles Helm charts, manifests, zipped deployment assets Versioned bundle, environment compatibility, link to related artifact versions

Mandatory

  • Publish releasable outputs to a managed location rather than keeping them only on ephemeral agents.
  • Keep artifacts immutable once released.
  • Keep a clear mapping between source revision, artifact version, and pipeline execution.

Expected

  • Apply retention rules that keep production and audit-relevant artifacts longer than short-lived CI builds.

Important

  • Use a consistent naming convention for artifact packages, containers, and installers.
  • Keep deployment artifacts distinct from source archives.

DHI good practice

  • Publish checksums, SBOMs, signatures, or attestations where the delivery channel benefits from them.

Desktop applications and installers

Desktop software should be included in CI/CD guidance just as much as web and service workloads.

Important

  • Build desktop binaries, installers, and supporting assets in CI rather than on developer machines.
  • Version installers and application binaries consistently so support and rollback are possible.
  • Where signing is part of the distribution model, perform signing through controlled pipeline steps and managed credentials.
  • Include smoke tests relevant to desktop delivery, for example install, launch, upgrade, or uninstall checks on a representative runner or test VM.

DHI good practice

  • Separate compile, package, sign, and publish steps so failures are easier to isolate.
  • Keep environment-specific packaging details outside the core build definition.
  • Automate upgrade-path tests for products with long-lived installed bases.

Continuous delivery and continuous deployment

  • Continuous Delivery means code is always in a deployable state and production release remains a deliberate decision.
  • Continuous Deployment means every change that passes the full quality bar is automatically deployed to production.

Mandatory

  • Products and shared components must have automated build validation.

Important

  • Teams should aim for continuous delivery as the default target: tested, versioned, and deployable outputs on demand.
  • Production releases should normally move through controlled environment promotion, especially for customer-facing systems.

DHI good practice

  • Continuous deployment to production is an advanced operating model, not the default. Adopt it only when rollback, observability, automated testing, and business approval expectations are mature.

Deployment strategy selection

Mandatory

  • Document the chosen production deployment strategy and rollback approach.

Adoption guidance

Strategy Adoption stance When to use Notes
Recreate / simple replace Allowed baseline Internal or lower-criticality systems where short downtime is acceptable Lowest complexity, weakest availability characteristics
Rolling deployment Default recommended Most services where the platform supports safe incremental replacement Good balance of simplicity and resilience
Blue/Green Recommended for high-availability workloads Customer-facing or business-critical services needing fast rollback Higher infrastructure cost but clearer rollback path
Canary / progressive delivery Optional advanced pattern Services with strong telemetry, alerting, and preferably feature flag support Do not adopt without observability maturity
Continuous deployment to production Optional advanced operating model Low-friction, low-risk domains with strong automated quality controls Governance and rollback expectations still apply

Infrastructure as Code integration

Application delivery and environment provisioning should not be treated as unrelated concerns.

Important

  • When a release depends on infrastructure changes, version and review the Infrastructure as Code with the same discipline as the application change.
  • Keep clear ownership of which pipeline or repository manages infrastructure changes versus application deployment changes.
  • Use the Infrastructure as Code Guidelines when defining how environments, identities, and cloud resources are provisioned.

DHI good practice

  • Use promotion-friendly IaC patterns such as reviewed plans, reusable modules, and consistent environment inputs.
  • Create temporary environments automatically when this reduces delivery risk and cost.

Secrets and credentials management

Mandatory

  • Pipelines must not hard-code secrets in code, configuration files, pipeline definitions, or logs.
  • Use managed secret stores or platform secret capabilities for runtime access.
  • Use least-privilege identities for build and deployment automation.

Important

  • Prefer short-lived credentials and federated identity where supported.
  • Separate identities and approvals by environment where this reduces blast radius.
  • Rotate secrets on a defined schedule and immediately after suspected exposure.

Supporting material in this folder

Starter pipeline templates are intentionally not maintained here. Use approved AI assistance to generate repository-specific scaffolding and ensure it complies with the guidance in this folder.

The following published guidelines already reference CI/CD guidance. This list will expand as more guidance is added:

References