61 lines
1.9 KiB
Markdown
61 lines
1.9 KiB
Markdown
# Deployment
|
|
|
|
## Scope
|
|
|
|
This workflow covers releasing CBDD as an internal package and promoting a validated version for downstream consumers.
|
|
|
|
## Promotion Path
|
|
|
|
1. Development validation on feature branch.
|
|
2. Merge to `main` after required quality gates.
|
|
3. Tag release and publish package artifact.
|
|
4. Consumer rollout to target services/tools.
|
|
|
|
## Pre-Deployment Checklist
|
|
|
|
1. Run repository fitness gate.
|
|
```bash
|
|
bash scripts/fitness-check.sh
|
|
```
|
|
2. Verify no pending incidents in current release window.
|
|
3. Confirm release notes include behavioral changes and migration notes.
|
|
4. Confirm package version bump strategy.
|
|
|
|
## Release Procedure
|
|
|
|
1. Build release artifacts.
|
|
```bash
|
|
dotnet build CBDD.slnx -c Release
|
|
dotnet test CBDD.slnx -c Release
|
|
```
|
|
2. Pack publishable projects.
|
|
```bash
|
|
dotnet pack src/CBDD/ZB.MOM.WW.CBDD.csproj -c Release -o nupkgs
|
|
```
|
|
3. Publish package to approved internal feed.
|
|
4. Create release tag and attach release notes.
|
|
5. Notify downstream teams of version and rollout guidance.
|
|
|
|
## Post-Deployment Validation
|
|
|
|
1. Install released package in a smoke-test consumer.
|
|
2. Validate insert, query, transaction commit, and recovery startup behavior.
|
|
3. Verify CDC, vector, and geospatial capabilities when used by consuming teams.
|
|
|
|
## Rollback Procedure
|
|
|
|
Trigger rollback when release validation fails or production consumers detect regression.
|
|
|
|
1. Stop further promotions of the failing version.
|
|
2. Revert to previous known-good package version in consumer manifests.
|
|
3. If package registry supports unlisting/yanking, unlist the bad version.
|
|
4. Open incident issue with impact, timeline, and containment actions.
|
|
5. Prepare and validate patch release before re-promotion.
|
|
|
|
## Emergency Change Path
|
|
|
|
1. Create hotfix branch from last good tag.
|
|
2. Apply minimal fix and run full quality gates.
|
|
3. Require maintainer approval.
|
|
4. Publish patched version and communicate mandatory upgrade guidance.
|