my-git

Release Management

English

Release management must ensure that versions are trackable, changes are explainable, and issues can be rolled back.

Git itself records version history, while GitHub Release, tags, changelogs, and CI/CD turn this history into deliverable version assets.

Recommended Artifacts

tag
release note
changelog
rollback plan
migration note
verification note

Release Process

merge -> tag -> release notes -> deploy -> verify -> announce

Tag Conventions

Semantic versioning is recommended:

v2.0.0
v2.0.1
v2.1.0

Common meanings:

major: Incompatible changes
minor: Backwards-compatible new features
patch: Backwards-compatible fixes

What Should Be in a Release Note

Include at least:

Key changes
Bug fixes
Breaking changes
Upgrade instructions
Rollback procedures
Contributors

See Release Note Template for a template.

Hotfix Releases

Hotfixes only address emergency issues in the production environment.

Principles:

Small diff
Do not mix in refactoring
Clear verification
Rollback plan in place
Backport to the trunk after release

For the process, see Hotfix Process.

Release Pipeline

Public practices like Netflix Spinnaker remind us that for many teams, the real risk is concentrated in the release process, of which the branching model is only a part.

Once a team has PRs, CI, and branch protection, the next things to add are:

Linking releases to commits or tags
Release records include release notes
Clear checkpoints before production release
Manual approval points for high-risk releases
Trackable verification results post-release
Clear rollback paths

See Netflix Spinnaker and Release Pipeline Practices for details.

Release Flow and Daily Deployment

The Microsoft Release Flow experience is suited for teams with fixed sprints and fixed release windows:

Daily development enters the trunk
Cut a release branch from the trunk before release
The release branch only accepts stability fixes
Sync back to the trunk after fixes are completed
Trace release versions using tags and release notes

Slack’s publicly shared deployment practices place more emphasis on “continuous small-batch releases”: breaking down risks into daily deployments through automated checks, deployment queues, observability, and rollback paths.

These two types of practices differ in direction, but their common ground is clear: release management cannot solely rely on branch naming; it must string together verifications, approval points, release records, monitoring, and rollback paths.

If the team has fixed release windows, Microsoft Release Flow can be prioritized as a reference. If the team deploys frequently, Slack Deploys and Netflix Spinnaker can be prioritized. For more case comparisons, see Big Tech Engineering Practice Decision Map.