Release Process

Before You Read

This guide covers versioning and release tagging. For how the release propagates to the cluster see GitOps Workflow.

Versioning Convention

[NEEDS TEAM INPUT: describe the versioning scheme used — semantic versioning (v1.2.3), date-based, commit SHA-based, or a combination. Is there a release-version file in each repo?]

The Bitbucket pipeline in infrastructure-management/bitbucket-pipelines.yml triggers on version tags matching *v* (e.g., v1.2.3).

Release Steps

1. Create a Release Tag

# In the microservice repository
git checkout main
git pull origin main

# Tag the release
git tag -a v1.2.3 -m "Release v1.2.3"
git push origin v1.2.3

2. CI Builds the Release Image

Bitbucket Pipelines builds and pushes:

us-central1-docker.pkg.dev/orofi-dev-cloud/orofi/{service-name}:v1.2.3

[NEEDS TEAM INPUT: does the pipeline also build a latest tag? Does it auto-update the infra repo?]

3. Update Infra Repo

Update the image tag in infrastructure-configuration with the release version:

# Example values.yaml update
image:
  tag: "v1.2.3"  # ← update from commit SHA to version tag

Commit and open a PR. After merge, ArgoCD deploys.

4. Tag the Infra Repo

[NEEDS TEAM INPUT: is there a practice of tagging the infra repo to record which versions are deployed to which environment?]

Release Notes

[NEEDS TEAM INPUT: describe where release notes live — Bitbucket, Confluence, a CHANGELOG.md file?]

Hotfix Process

For critical production bugs:

1. Create a hotfix branch from the production tag: git checkout -b hotfix/v1.2.4 v1.2.3
2. Apply the fix and commit
3. Tag: git tag v1.2.4
4. Push and open PR for review
5. After merge, follow GitOps Workflow for deployment

Rollback

If a release is bad, see Rollbacks for immediate response, then follow the hotfix process above.

See Also

• GitOps Workflow
• Rollbacks