AzuTear
99 lines
2.7 KiB
Markdown
99 lines
2.7 KiB
Markdown
# Release Process
|
|
|
|
This document defines the default release process.
|
|
|
|
For daily delivery flow, see [workflow.md](workflow.md).
|
|
For branch policy, see [branching.md](branching.md).
|
|
For release checklist, see [CHECKLISTS.md](CHECKLISTS.md#release).
|
|
|
|
## Release Principles
|
|
|
|
- Release small changes when practical.
|
|
- Prefer repeatable automation over manual steps.
|
|
- Validate before and after deployment.
|
|
- Keep rollback or recovery options ready.
|
|
- Record production-impacting decisions.
|
|
|
|
## Release Types
|
|
|
|
| Type | Description | Example |
|
|
| --- | --- | --- |
|
|
| Standard | Planned release through the normal pipeline. | Weekly feature release. |
|
|
| Hotfix | Urgent production fix. | Authorization regression fix. |
|
|
| Experimental | Limited rollout or feature flag release. | Beta feature for selected users. |
|
|
| Infrastructure | Runtime, hosting, network, or dependency change. | Database engine upgrade. |
|
|
|
|
## Versioning
|
|
|
|
Choose the versioning model that matches the project:
|
|
|
|
- Semantic versioning for libraries, APIs, SDKs, and installable packages.
|
|
- Calendar versioning for operational products with frequent releases.
|
|
- Build numbers or commit SHAs for internal services.
|
|
|
|
Document the chosen model in [PROJECT.md](PROJECT.md).
|
|
|
|
## Readiness
|
|
|
|
Before release:
|
|
|
|
- Scope is confirmed.
|
|
- Required checks pass.
|
|
- Migrations are reviewed.
|
|
- Configuration is ready.
|
|
- Secrets are present in the target environment.
|
|
- Rollback or recovery plan exists.
|
|
- Monitoring is available.
|
|
- Stakeholders know the release window when needed.
|
|
|
|
## Deployment
|
|
|
|
Deployment steps:
|
|
|
|
1. Confirm target environment.
|
|
2. Confirm release version or commit.
|
|
3. Run pre-deploy checks.
|
|
4. Deploy.
|
|
5. Run migrations when required by the release plan.
|
|
6. Run smoke tests.
|
|
7. Monitor health and error signals.
|
|
8. Announce completion or rollback.
|
|
|
|
## Smoke Tests
|
|
|
|
Smoke tests should prove that the release is alive and the most important path
|
|
works.
|
|
|
|
Examples:
|
|
|
|
- Health endpoint returns success.
|
|
- Application loads.
|
|
- Login works.
|
|
- Critical API endpoint succeeds.
|
|
- Background worker starts.
|
|
- Database connectivity is healthy.
|
|
|
|
## Rollback And Recovery
|
|
|
|
Rollback planning should address:
|
|
|
|
- Application artifact rollback.
|
|
- Database migration rollback or forward fix.
|
|
- Configuration rollback.
|
|
- Feature flag disablement.
|
|
- Queue or job replay behavior.
|
|
- External dependency failure.
|
|
|
|
If database changes are not reversible, document the recovery path before
|
|
deployment.
|
|
|
|
## Post-Release Review
|
|
|
|
After release:
|
|
|
|
- Confirm monitoring is quiet or expected.
|
|
- Record incidents or anomalies.
|
|
- Update docs if release steps drifted.
|
|
- Add follow-up tasks for manual work discovered during release.
|
|
- Capture lessons in checklists or ADRs when they change future behavior.
|