|
| 1 | +--- |
| 2 | +title: Release Process |
| 3 | +description: Learn the weekly release rhythm, validation model, and release execution process for Thunder. |
| 4 | +sidebar_position: 4 |
| 5 | +hide_table_of_contents: false |
| 6 | +--- |
| 7 | + |
| 8 | +# Release Process |
| 9 | + |
| 10 | +This page explains how Thunder moves changes from development to a weekly release. |
| 11 | + |
| 12 | +--- |
| 13 | + |
| 14 | +## 📅 Release Cadence |
| 15 | + |
| 16 | +Thunder follows a weekly release cycle. Work is planned, developed, and validated within a fixed weekly window. |
| 17 | + |
| 18 | +| Day | Activity | |
| 19 | +| --- | --- | |
| 20 | +| Monday | Weekly sync to plan the milestone, assign work, and confirm scope | |
| 21 | +| Monday to Thursday | Development, pull requests, reviews, and iteration | |
| 22 | +| Thursday 9:30 PM UTC (Friday 3:00 AM IST) | Pre-Release Sync: release branch created (if needed) and synced from main | |
| 23 | +| Friday | Validate milestone changes against the draft release; fix or revert issues directly on the release branch, then release | |
| 24 | + |
| 25 | +--- |
| 26 | + |
| 27 | +## Branch Model |
| 28 | + |
| 29 | +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 validation is complete and the release is successful, the release branch is merged back into `main` automatically. |
| 30 | + |
| 31 | +```text |
| 32 | +main ──●──●──●──●──┬──●──●──●──── (development continues) |
| 33 | + │ |
| 34 | + └── release ──○──○──◆ tag vX.Y.Z |
| 35 | + │ │ │ |
| 36 | + fixes merge back to main |
| 37 | + validated |
| 38 | +``` |
| 39 | + |
| 40 | +:::warning Avoid duplicate merges across branches |
| 41 | + |
| 42 | +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. |
| 43 | + |
| 44 | +::: |
| 45 | + |
| 46 | +--- |
| 47 | + |
| 48 | +## 🧪 Release Validation |
| 49 | + |
| 50 | +Every change included in the milestone must be validated by someone other than the author before release. |
| 51 | + |
| 52 | +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. |
| 53 | + |
| 54 | +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. |
| 55 | + |
| 56 | +--- |
| 57 | + |
| 58 | +## 🔖 Release Manager Responsibilities |
| 59 | + |
| 60 | +The Release Manager coordinates release readiness and final release execution. |
| 61 | + |
| 62 | +1. **Lead the weekly sync** — confirm milestone scope and identify at-risk work. |
| 63 | +2. **Review readiness on Thursday** — check milestone issues and pull requests for blockers. |
| 64 | +3. **Create a draft release** — publish a draft GitHub release to verify release artifacts before going live. |
| 65 | +4. **Coordinate release validation** — confirm all milestone changes are validated against the draft release. |
| 66 | +5. **Trigger the Release Builder** — run the workflow manually once everything is confirmed good to release, or allow the scheduled release run. |
| 67 | +6. **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. |
| 68 | + |
| 69 | +--- |
| 70 | + |
| 71 | +## 🚨 When Issues Arise |
| 72 | + |
| 73 | +> **Default stance: revert and release on time.** |
| 74 | +A predictable release train matters more than any single feature. |
| 75 | + |
| 76 | +| Situation | Action | |
| 77 | +| --- | --- | |
| 78 | +| Milestone change fails and quick fix is clear | Author fixes on release branch and re-validates | |
| 79 | +| Milestone change fails and fix is complex | Revert from release branch, release without it, carry to next week | |
| 80 | +| Release validation fails and cause is clear | Revert causing change and release without it | |
| 81 | +| Release validation fails and cause is unclear | Revert suspected change and investigate on main next week | |
| 82 | + |
| 83 | + |
| 84 | + |
| 85 | +--- |
| 86 | + |
| 87 | +## ⚙️ Automation Workflows |
| 88 | + |
| 89 | +The weekly release process uses these GitHub Actions workflows: |
| 90 | + |
| 91 | +| Workflow | Trigger | What It Does | |
| 92 | +| --- | --- | --- | |
| 93 | +| [Pre-Release Sync](https://github.com/asgardeo/thunder/blob/main/.github/workflows/pre-release-sync.yml) | Thursday 9:30 PM UTC and manual dispatch | Merges main into release branch; commits directly if no conflicts, opens a PR otherwise | |
| 94 | +| [Release Milestone Reminder](https://github.com/asgardeo/thunder/blob/main/.github/workflows/release-milestone-reminder.yaml) | Thursday 6:00 AM IST and manual dispatch | Sends release-readiness reminder based on open milestone items | |
| 95 | +| [Release Builder](https://github.com/asgardeo/thunder/blob/main/.github/workflows/release-builder.yml) | Scheduled on Friday and manual dispatch | Builds, tags, packages, and publishes the release | |
| 96 | +| [Post-Release Sync](https://github.com/asgardeo/thunder/blob/main/.github/workflows/post-release-sync.yml) | After successful release workflow run and manual dispatch | Merges release into main directly if no conflicts; opens a conflict-resolution PR otherwise | |
0 commit comments