Skip to content

Deployment

This page describes how the DevOps / GitOps Platform itself is deployed and operated. Like everything in the factory, the platform is deployed onto the Runtime & Cloud Platform using its own GitOps discipline — it ships itself the same way it ships generated modules.

Target Architecture — Final-State Design

The platform runs as containerized .NET 10 services and workers. Infrastructure for the platform is itself authored in Pulumi (.NET/C#) and reconciled via GitOps.

Runtime Model

  • Compute — services and workers run as containers on Azure Kubernetes Service (AKS); lighter workers and burst workloads can run on Azure Container Apps. Both consume images from ACR.
  • Hosting — each of the 14 microservices is an ASP.NET Core host (REST + gRPC) from the ConnectSoft.MicroserviceTemplate; each of the 11 workers is a ConnectSoft.WorkerTemplate background service.
  • Messaging — MassTransit on Azure Service Bus connects services and workers.
  • Ingress — north-south traffic flows through the factory API gateway (ConnectSoft.ApiGatewayTemplate) with TLS termination and auth.

Deployment Topology

flowchart TB
    Gateway["API Gateway"] --> AKS
    subgraph AKS["AKS Cluster"]
        subgraph SvcPool["Service Node Pool"]
            Services["DevOps microservices (14)"]
        end
        subgraph WorkerPool["Worker Node Pool"]
            Workers["DevOps workers (11)"]
        end
    end
    Services --> SB["Azure Service Bus"]
    Workers --> SB
    Services --> SQL["Azure SQL / PostgreSQL"]
    Services --> Blob["Azure Blob"]
    Workers --> ACR["Azure Container Registry"]
    Workers --> Artifacts["Azure Artifacts"]
    Workers --> Pulumi["Pulumi backend"]
    Services --> KeyVault["Azure Key Vault"]
    Workers --> KeyVault
Hold "Alt" / "Option" to enable pan & zoom

Scaling

  • Services scale horizontally on CPU/RPS via the Horizontal Pod Autoscaler; read-heavy services (PullRequest, BuildResult) scale independently of write-heavy ones.
  • Workers scale on Service Bus queue depth via KEDA — for example, ContainerBuildWorker and PipelineMonitorWorker scale out during release waves and back to zero when idle.
  • Stateful backends (Azure SQL) scale via tier/replica; large tenants can be sharded (see Data Model).

Configuration

  • Configuration follows the options pattern (ConnectSoft.Extensions.Options), layered from defaults → environment → tenant overrides.
  • Environment-specific settings are delivered via Kubernetes ConfigMaps generated from Git (GitOps), never hand-edited in the cluster.
  • Feature flags and rollout controls are sourced centrally so behavior is consistent and auditable.

Secrets

  • Secrets are mounted from Azure Key Vault via the Secrets Store CSI driver and managed identities — no secrets in images, ConfigMaps, or Git.
  • Database connection strings, Service Bus, ACR, Artifacts, and cloud credentials resolve at runtime through workload identity.

Health

  • Each service/worker exposes liveness, readiness, and startup probes via ConnectSoft.Extensions.Diagnostics.HealthChecks, aggregated by ConnectSoft.HealthChecksAggregatorTemplate.
  • Readiness gates dependency availability (DB, Service Bus) so traffic is only routed to healthy pods.
  • Deployment health gates (used during promotion) verify probe status and key metrics before a release is marked Deployed.

Deployment Strategy

  • The platform deploys via GitOps: desired manifests live in Git; the GitOps controller on AKS reconciles them — the same mechanism the platform offers to generated modules.
  • Strategies supported for the platform and its tenants: rolling update (default), blue/green, and canary, with automated rollback on failed health gates.

Pillar Alignment

  • Reusability — the platform deploys itself with the same templates and GitOps flow it provides to others.
  • Multi-tenant scale — node pools, HPA/KEDA autoscaling, and SQL sharding support large multi-tenant estates.
  • Observability — health probes and metrics gate every deployment.