|
| 1 | +--- |
| 2 | +title: Release Operations |
| 3 | +description: Learn the weekly release rhythm, validation model, and release execution process for Thunder. |
| 4 | +sidebar_position: 3 |
| 5 | +hide_table_of_contents: false |
| 6 | +--- |
| 7 | + |
| 8 | +# Release Operations |
| 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 | +```text |
| 30 | +main ──●──●──●──●──┬──●──●──●──── (development continues) |
| 31 | + │ |
| 32 | + └── release ──○──○──◆ tag vX.Y.Z |
| 33 | + │ │ │ |
| 34 | + fixes merge back to main |
| 35 | + validated |
| 36 | +``` |
| 37 | + |
| 38 | +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. |
| 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 | +
|
| 75 | +| Situation | Action | |
| 76 | +| --- | --- | |
| 77 | +| Milestone change fails and quick fix is clear | Author fixes on release branch and re-validates | |
| 78 | +| Milestone change fails and fix is complex | Revert from release branch, release without it, carry to next week | |
| 79 | +| Release validation fails and cause is clear | Revert causing change and release without it | |
| 80 | +| Release validation fails and cause is unclear | Revert suspected change and investigate on main next week | |
| 81 | + |
| 82 | +A predictable release train matters more than any single feature. |
| 83 | + |
| 84 | +--- |
| 85 | + |
| 86 | +## ⚙️ Automation Workflows |
| 87 | + |
| 88 | +The weekly release process uses these GitHub Actions workflows: |
| 89 | + |
| 90 | +| Workflow | Trigger | What It Does | |
| 91 | +| --- | --- | --- | |
| 92 | +| [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 | |
| 93 | +| [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 | |
| 94 | +| [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 | |
| 95 | +| [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