Skip to content
Sunny Calculator Add-On

ADR-010 - Deployment Process

Statusaccepted
Date2025-04-15
Decision MakersDardan Bujupaj (AX), Marc Gähwiler (AX), Markus Brenner (Griesser)
Referenced ByADR-011 - CI/CD Platform

Context

This document details the process for deploying the Sunny Calculator AddOn through the defined environments and the strategy for promoting builds between them.

With the deployment environments defined in ADR-009 - Deployment Environments, we need a clear, reliable, and partially automated process to move code changes from development towards production. This process must incorporate automated quality checks, allow for essential manual user validation, and ensure that production releases are explicitly approved by the business stakeholders at Griesser. We aim to leverage the Azure DevOps tooling mandated by the ADR-004 - Infrastructure ADR.

Decision

The deployment process will adhere to the following steps:

  1. Development & Pre-Merge: Developers work on features locally or on a feature branch. Continuous Integration (CI) checks, including unit tests, linting, and builds, run automatically (via Azure Pipelines) on pushes to feature branches and before merging to the main integration branch (main).
  2. Deployment to Integration Test (INT): Upon successful merge of a completed feature (potentially including dependent service updates) to the main branch where all tests pass, Azure Pipelines automatically deploys the build to the INT environment.
  3. Automated Testing in INT: Following deployment to INT, Azure Pipelines automatically executes the automated test suite, primarily focusing on integr~~ation tests and end-to-end (E2E) tests that verify component interactions and key user flows within the deployed environment.
  4. Promotion to User Acceptance Test (UAT): If all automated tests in the INT environment pass successfully, Azure Pipelines automatically promotes and~~ deploys the same build that passed testing to the UAT environment.
  5. Manual Testing in UAT: Designated users and stakeholders from Griesser perform manual testing in the UAT environment to validate functionality against business requirements and acceptance criteria. Automated checks might supplement this, but manual sign-off is key.
  6. Production Deployment Trigger: Deployment to the Production environment is NOT fully automatic. After successful UAT and explicit sign-off from authorized personnel at Griesser, they will manually trigger a dedicated Azure Pipelines release workflow.
  7. Automated Production Release: Once triggered manually, the Azure Pipelines workflow executes the automated steps required to deploy the UAT-approved build to the Production environment (potentially using strategies like blue-green or canary deployments if configured).

Consequences

  • Benefits:
    • Balances automation efficiency (DEV -> UAT) with necessary manual control for Production releases.
    • Establishes clear quality gates (automated tests in INT, manual validation in UAT).
    • Provides traceability, as the same build artifact progresses through INT, UAT, and Prod.
    • Leverages existing Azure DevOps tooling per infrastructure standards.
    • Reduces risk of accidental production deployments.
  • Drawbacks:
    • The overall release cadence is dependent on the availability and speed of Griesser personnel for UAT and Production triggering.
    • Requires a robust and reliable automated test suite for the INT gate to be effective.
    • Needs clear processes and communication channels for UAT feedback, sign-off, and production deployment requests.
  • Requires: Well-maintained Azure Pipelines configurations, clear definition of UAT sign-off criteria, and identified personnel at Griesser responsible for triggering production deployments.

Alternatives

  • Fully Automated Promotion to Production:
    • Pros: Maximizes deployment speed.
    • Cons: Removes the critical business validation and explicit approval step before impacting live users, significantly increasing risk. This does not meet Griesser’s requirement for manual release control.
  • Fully Manual Deployments:
    • Pros: Complete control at every stage.
    • Cons: Extremely slow, error-prone, resource-intensive, and contrary to CI/CD best practices where automation is feasible and beneficial.
  • Running E2E/Integration Tests Earlier (Pre-Merge CI):
    • Pros: Catches integration issues even earlier.
    • Cons: Often significantly slower and more complex to set up reliably in a pre-merge CI context compared to testing against a deployed INT environment. INT remains the primary environment for verifying the integrated system.