Add enterprise docs structure and include pending core maintenance updates.
This commit is contained in:
60
docs/deployment.md
Normal file
60
docs/deployment.md
Normal file
@@ -0,0 +1,60 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user