Release Operations
This page explains how ThunderID moves changes from development to a weekly release.
📅 Release Cadence
ThunderID follows a weekly release cycle. Work is planned, developed, and validated within a fixed weekly window.
| Day | Activity |
|---|---|
| Monday | Weekly sync to plan the milestone, assign work, and confirm scope |
| Monday to Thursday | Development, pull requests, reviews, and iteration |
| Thursday 9:30 PM UTC (Friday 3:00 AM IST) | Pre-Release Sync: release branch created (if needed) and synced from main |
| Friday | Validate milestone changes against the draft release; fix or revert issues directly on the release branch, then release |
Branch Model
main ──●──●──●──●──┬──●──●──●──── (development continues)
│
└── release ──○──○──◆ tag vX.Y.Z
│ │ │
fixes merge back to main
validated
Development happens continuously on main. On Thursday night, the Pre-Release Sync merges the latest changes from main into release branch. Any fixes identified during release validation are applied directly to the release branch. Once everything is validated and the release is confirmed good, the workflow tags it and merges it back into main automatically.
Do not merge the same change into both main and release separately. Each change should live in exactly one branch - merging it into both can cause duplication or conflicts when the branches are synced.
🧪 Release Validation
Every change included in the milestone must be validated by someone other than the author before release.
A draft release is created before the final release to allow validation of all milestone changes against real release artifacts. If any issues are found during validation, fixes should be applied directly to the release branch and re-validated. Development can continue on main as usual during this time - only release-related fixes go into the release branch.
Alongside milestone-specific changes, core IAM flows - including authentication, authorization, and token management - are tested every release, regardless of what changed. This ensures baseline functionality is never silently broken between releases.
🔖 Release Manager Responsibilities
The Release Manager coordinates release readiness and final release execution.
- Lead the weekly sync - confirm milestone scope and identify at-risk work.
- Review readiness on Thursday - check milestone issues and pull requests for blockers.
- Create a draft release - publish a draft GitHub release to verify release artifacts before going live.
- Coordinate release validation - confirm all milestone changes are validated against the draft release.
- Trigger the Release Builder - run the workflow manually once everything is confirmed good to release, or allow the scheduled release run.
- Confirm post-release sync - verify the release branch is merged back into main, ensure the milestone is closed and release notes are generated properly, and update stakeholders.
🚨 When Issues Arise
Default stance: revert and release on time.
| Situation | Action |
|---|---|
| Milestone change fails and quick fix is clear | Author fixes on release branch and re-validates |
| Milestone change fails and fix is complex | Revert from release branch, release without it, carry to next week |
| Release validation fails and cause is clear | Revert causing change and release without it |
| Release validation fails and cause is unclear | Revert suspected change and investigate on main next week |
A predictable release train matters more than any single feature.
⚙️ Automation Workflows
The weekly release process uses these GitHub Actions workflows:
| Workflow | Trigger | What It Does |
|---|---|---|
| Pre-Release Sync | Thursday 9:30 PM UTC and manual dispatch | Merges main into release branch; commits directly if no conflicts, opens a PR otherwise |
| Release Milestone Reminder | Thursday 6:00 AM IST and manual dispatch | Sends release-readiness reminder based on open milestone items |
| Release Builder | Scheduled on Friday and manual dispatch | Builds, tags, packages, and publishes the release |
| Post-Release Sync | After successful release workflow run and manual dispatch | Merges release into main directly if no conflicts; opens a conflict-resolution PR otherwise |
