CI/CD & Environments

Azure DevOps controlled how library changes moved through the environment chain.

Release flow

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

Environment behavior

Environment	Deployment behavior
Test	Updated automatically after changes reached the deployment branch
Acceptance	Promotion required approval
Production	Promotion required a second approval

Why this was better than manual uploads

Before automation, file movement can easily become an operational task:

developer
  ↓
copy file
  ↓
upload manually
  ↓
hope correct environment was changed

The pipeline turns that into:

repository
  ↓
repeatable deployment
  ↓
controlled promotion

Release responsibility

The workflow separates two concerns:

• developers create and validate changes
• controlled approvals govern higher environments

That gives faster iteration in Test without removing control from Acceptance and Production.

Sanitized version of the original architecture

The original project diagram contained real internal environment names and URLs. The public version intentionally reduces it to the architecture that matters:

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