|
| 1 | +# Dual Build GitHub Pages Strategy |
| 2 | + |
| 3 | +## Purpose |
| 4 | + |
| 5 | +Document a clean migration strategy for delivering both stable and overhaul UI versions from one repository without adding runtime feature flags to application code. |
| 6 | + |
| 7 | +## Core Idea |
| 8 | + |
| 9 | +Build two versions of the site during deployment and publish both under one GitHub Pages branch. |
| 10 | + |
| 11 | +- Stable site at root path: /index.html |
| 12 | +- Overhaul site at next path: /next/index.html |
| 13 | + |
| 14 | +The URL path acts as the switch. |
| 15 | + |
| 16 | +- Stable: /develop/ |
| 17 | +- Overhaul: /develop/next/ |
| 18 | + |
| 19 | +## Why This Approach |
| 20 | + |
| 21 | +1. Keeps runtime code clean. |
| 22 | +2. Avoids pervasive if version checks in app modules. |
| 23 | +3. Allows side-by-side validation of stable and next UX. |
| 24 | +4. Reduces long-term cleanup work versus in-app toggles. |
| 25 | + |
| 26 | +## Deployment Layout |
| 27 | + |
| 28 | +Publish a combined artifact to the GitHub Pages branch with this shape: |
| 29 | + |
| 30 | +- /index.html and root assets from stable branch build |
| 31 | +- /next/index.html and next assets from overhaul branch build |
| 32 | + |
| 33 | +## CI Workflow Design |
| 34 | + |
| 35 | +A deployment workflow builds both branches in one run and publishes one artifact. |
| 36 | + |
| 37 | +1. Checkout stable branch into an isolated worktree directory. |
| 38 | +2. Install dependencies and build stable output. |
| 39 | +3. Copy stable output into publish root. |
| 40 | +4. Checkout overhaul branch into a second isolated worktree directory. |
| 41 | +5. Install dependencies and build overhaul output. |
| 42 | +6. Copy overhaul output into publish root under /next. |
| 43 | +7. Deploy combined publish folder to GitHub Pages. |
| 44 | + |
| 45 | +## Operational Guidance |
| 46 | + |
| 47 | +1. Run both builds in isolated directories to prevent cross-branch contamination. |
| 48 | +2. Keep Node and npm versions pinned consistently in CI. |
| 49 | +3. Use workflow concurrency to cancel outdated deploy jobs. |
| 50 | +4. Use relative asset URLs so content works under both root and /next paths. |
| 51 | +5. Fail the deploy if either build fails. |
| 52 | + |
| 53 | +## Source Control Model |
| 54 | + |
| 55 | +- main branch represents stable production UX. |
| 56 | +- overhaul branch represents next-generation UX. |
| 57 | +- Deploy workflow may trigger on pushes to either branch, but each run should still build both branches for a consistent dual-output artifact. |
| 58 | + |
| 59 | +## Relationship To App Architecture Work |
| 60 | + |
| 61 | +This strategy complements the multi-tab and local workspace migration by separating rollout concerns from runtime logic. |
| 62 | + |
| 63 | +- Runtime implementation remains modular and focused on architecture. |
| 64 | +- Deployment controls the exposure of stable versus next. |
| 65 | + |
| 66 | +## Tradeoffs |
| 67 | + |
| 68 | +Pros: |
| 69 | + |
| 70 | +1. Cleaner codebase during migration. |
| 71 | +2. Lower risk of runtime toggle regressions. |
| 72 | +3. Clear QA and stakeholder review URLs. |
| 73 | + |
| 74 | +Cons: |
| 75 | + |
| 76 | +1. Longer deploy times due to dual builds. |
| 77 | +2. More CI configuration complexity. |
| 78 | +3. Temporary branch coordination requirements. |
| 79 | + |
| 80 | +## Exit Plan |
| 81 | + |
| 82 | +After next UI is production-ready: |
| 83 | + |
| 84 | +1. Promote next code into main. |
| 85 | +2. Remove dual-build deployment logic. |
| 86 | +3. Publish only root output again. |
| 87 | +4. Remove migration-only docs and branch conventions. |
| 88 | + |
| 89 | +## Suggested Follow-up |
| 90 | + |
| 91 | +1. Add a deploy workflow implementation doc with exact GitHub Actions YAML and permissions. |
| 92 | +2. Add a release checklist for validating both URLs before each deploy. |
| 93 | +3. Add ownership notes for stable and next branch review responsibilities. |
0 commit comments