CI/CD & Omgevingen

Azure DevOps bepaalde hoe wijzigingen in de library door de omgevingsketen bewogen.

Release-flow

Feature branch
      │
      ▼
Pull request / merge
      │
      ▼
   main branch
      │
      ▼
Azure DevOps-pipeline
      │
      ▼
┌─────────────────┐
│      TEST       │  automatische deployment
└────────┬────────┘
         │
         ▼
    Approval gate
         │
         ▼
┌─────────────────┐
│   ACCEPTANCE    │
└────────┬────────┘
         │
         ▼
    Approval gate
         │
         ▼
┌─────────────────┐
│   PRODUCTION    │
└─────────────────┘

Gedrag per omgeving

Omgeving	Deploymentgedrag
Test	Automatisch bijgewerkt nadat wijzigingen de deploymentbranch bereikten
Acceptance	Promotie vereiste approval
Production	Promotie vereiste een tweede approval

Waarom dit beter was dan handmatig uploaden

Zonder automatisering kan file delivery snel een operationele taak worden:

developer
  ↓
bestand kopiëren
  ↓
handmatig uploaden
  ↓
hopen dat de juiste omgeving is aangepast

De pipeline maakt daarvan:

repository
  ↓
herhaalbare deployment
  ↓
gecontroleerde promotie

Verantwoordelijkheid bij releases

De workflow scheidt twee zaken:

• developers maken en valideren wijzigingen
• gecontroleerde approvals bepalen promotie naar hogere omgevingen

Zo blijft Test snel, terwijl Acceptance en Production gecontroleerd blijven.

Opgeschoonde versie van de oorspronkelijke architectuur

Het oorspronkelijke projectdiagram bevatte echte interne omgevingsnamen en URL's. De publieke versie laat alleen de relevante architectuur zien:

branch → main → Azure DevOps
                    │
                    ├── Test Blob → Planon Test
                    │
                    ├── approval → Acc Blob → Planon Acceptance
                    │
                    └── approval → Prod Blob → Planon Production