Skip to content

Storage

The DevOps / GitOps Platform follows a single-owner storage model: each datum has exactly one owning service and one authoritative store. Relational stores hold delivery metadata; specialized systems hold the heavy, authoritative content (source, packages, images, infra state, logs).

Target Architecture — Final-State Design

Azure SQL is the default relational store; PostgreSQL is supported via ConnectSoft.Extensions.PersistenceModel.PostgreSQL for tenants standardizing on it. Authoritative content always lives in its purpose-built system, never duplicated into the metadata store.

Storage Catalog

Data Store Owner Service Access Pattern Retention Notes
Repository metadata Azure SQL / PostgreSQL RepositoryService Read-heavy lookups by tenant/project Project lifetime Git tree authoritative in Azure DevOps
Branch metadata Azure SQL / PostgreSQL BranchService Read by repo; write on create Project lifetime Refs reconciled with Azure DevOps
Commit metadata Azure SQL / PostgreSQL CommitService Append-only writes; lineage reads Project lifetime Content in Azure DevOps Git
Pull request records Azure SQL / PostgreSQL PullRequestService Read/write during review 24 months post-merge Merge state reconciled with Azure DevOps
Pipeline definitions Azure SQL / PostgreSQL PipelineGeneratorService Write on generate; read on run Project lifetime YAML committed to repo
Pipeline runs Azure SQL / PostgreSQL PipelineExecutionService High-write during runs 12 months hot Status mirrored from Azure DevOps
Build results Azure SQL / PostgreSQL BuildResultService Write once; read by release 12 months hot, then archive Metadata only
Build logs / artifacts Azure Blob Storage BuildResultService Write-once; occasional read 12 months (lifecycle policy) Large objects out of SQL
Release plans / approvals / promotions Azure SQL / PostgreSQL ReleaseService, EnvironmentPromotionService Read/write during release 7 years Compliance audit
Deployment manifests Azure Blob + GitOps repo DeploymentManifestService Write-once; read on deploy Project lifetime Committed to GitOps repo
NuGet packages Azure Artifacts PackagePublishingService Publish-once; restore reads Per feed policy Immutable versions
Container images Azure Container Registry (ACR) ContainerImageService Push-once; pull on deploy Per registry retention Digest-addressed; scanned
Infrastructure state Pulumi backend IaCProvisioningService Lock + read/write on apply State lifetime Pulumi managed/self-hosted backend
GitOps sync state Azure SQL / PostgreSQL GitOpsSyncService Reconcile loop read/write Current + 90-day history Desired state in Git
Source of truth (code/IaC) Azure DevOps Git Source Control context Clone/push via agents Project lifetime GitHub optional secondary

Source of Truth

  • Code and IaC: Azure DevOps Git repositories are the authoritative source. The relational metadata stores are projections/indexes over that truth for fast querying and lineage; they are rebuildable from Git + event replay.
  • Packages: Azure Artifacts NuGet feeds (the same feeds used by the factory today — see the local _local-nuget mirror for offline development).
  • Images: Azure Container Registry, digest-addressed and vulnerability-scanned.
  • Infrastructure: Pulumi backend holds stack state; the Pulumi C# program is itself versioned in Git.

Access & Isolation

  • All relational access goes through NHibernate repositories with ConnectSoft.Extensions.Saas.NHibernate tenant filters.
  • Blob containers, Artifacts feeds, and ACR repositories are namespaced per tenant/project, with access governed by managed identities and Key Vault-issued credentials.
  • No service queries another service's store; cross-service data is obtained via APIs or events.

Backup & Disaster Recovery

  • Azure SQL: point-in-time restore + geo-redundant backups.
  • Blob: geo-redundant storage (GRS) with lifecycle tiering to cool/archive.
  • Azure DevOps, Artifacts, ACR: provider-managed redundancy; critical feeds/registries are geo-replicated.
  • Pulumi state: backend-replicated; the program-in-Git allows full reconstruction.

Pillar Alignment

  • Traceability — metadata stores index the authoritative content for lineage queries.
  • Multi-tenant scale — per-tenant namespacing and shardable SQL support large estates.
  • Governance — long retention on releases/approvals and immutable packages/images support audit.