|
12 | 12 | * [Branches naming](#branches-naming) |
13 | 13 | * [Branching visualization](#branching-visualization) |
14 | 14 | * [Feature and fix branches that are merged into the main branch](#feature-and-fix-branches-that-are-merged-into-the-main-branch) |
15 | | - * [Cherry picking changes into release (stable) branch from the main branch](#cherry-picking-changes-into-release-stable-branch-from-the-main-branch) |
| 15 | + * [Cherry-picking changes into release (stable) branch from the main branch](#cherry-picking-changes-into-release-stable-branch-from-the-main-branch) |
16 | 16 | * [Multiple release branches, fixes made in fix branches](#multiple-release-branches-fixes-made-in-fix-branches) |
| 17 | +* [Branching strategy](#branching-strategy) |
| 18 | + * [Steps (ordered)](#steps-ordered) |
| 19 | + * [Visualized flow](#visualized-flow) |
| 20 | + * [Cherry picking](#cherry-picking) |
| 21 | +* [Git workflow](#git-workflow) |
| 22 | + * [New release branch](#new-release-branch) |
| 23 | + * [Update/fix existing release branch](#updatefix-existing-release-branch) |
17 | 24 |
|
18 | 25 | <!-- vim-markdown-toc --> |
19 | 26 |
|
@@ -160,3 +167,150 @@ branch naming conventions are not covered here. |
160 | 167 |
|
161 | 168 | [branching_3](https://lightspeed-core.github.io/lightspeed-stack/branching_3.svg) |
162 | 169 |
|
| 170 | + |
| 171 | +## Branching strategy |
| 172 | + |
| 173 | +### Steps (ordered) |
| 174 | + |
| 175 | +1. Create release branch |
| 176 | + |
| 177 | +2. Update metadata, such us version etc. |
| 178 | + |
| 179 | +3. Run CI: full test suite, linters, build (this is to check that branching is |
| 180 | + ok) |
| 181 | + |
| 182 | +4. Stabilize: apply bug fixes, adjust configurations, small polish commits on |
| 183 | + release branch |
| 184 | + |
| 185 | +5. QA / UAT: Deploy release branch to staging environment (Konflux) |
| 186 | + |
| 187 | +6. Fix issues: commit fixes directly on release branch; re-run CI |
| 188 | + |
| 189 | +7. Prepare release: Finalize changelog, update docs, set release notes |
| 190 | + |
| 191 | +8. Deploy: trigger production deployment (Konflux) |
| 192 | + |
| 193 | +9. Hotfixes (if needed): create hotfix/x.y.z+1 from main, then follow same flow |
| 194 | + |
| 195 | + |
| 196 | + |
| 197 | +### Visualized flow |
| 198 | + |
| 199 | +``` |
| 200 | + +-----------------+ |
| 201 | + | main branch | |
| 202 | + | | |
| 203 | + +--------+--------+ |
| 204 | + | |
| 205 | + | create release/x.y.z |
| 206 | + v |
| 207 | + +-----------------+ |
| 208 | + | release/x.y.z | |
| 209 | + | (stabilize) | |
| 210 | + +----+---+---+----+ |
| 211 | + | | | |
| 212 | + update changelog | | | bug fixes & CI |
| 213 | + | | | |
| 214 | + v v v |
| 215 | + +-----------------+ |
| 216 | + | Run CI / Tests | |
| 217 | + +--------+--------+ |
| 218 | + | |
| 219 | + v |
| 220 | + +-----------------+ |
| 221 | + | Run e2e tests | |
| 222 | + | in Konflux | |
| 223 | + | | |
| 224 | + +--------+--------+ |
| 225 | + | |
| 226 | + issues found | validated |
| 227 | + +--------+-----------+ |
| 228 | + | | |
| 229 | + v v |
| 230 | + +----------------+ +----------------+ |
| 231 | + | Fix on release | | Ready for ship | |
| 232 | + +-------+--------+ +-------+--------+ |
| 233 | + | | |
| 234 | + v v |
| 235 | + (re-run CI) tag the release |
| 236 | + | | |
| 237 | + v v |
| 238 | + +----------------+ +----------------+ |
| 239 | + | return to QA | | (tag vX) |------------+ |
| 240 | + +----------------+ +----------------+ | |
| 241 | + | | |
| 242 | + v v |
| 243 | + +----------------+ +-----------------+ |
| 244 | + | Build images | | Publish on PyPi | |
| 245 | + +----------------+ +-----------------+ |
| 246 | +``` |
| 247 | + |
| 248 | + |
| 249 | + |
| 250 | +### Cherry picking |
| 251 | + |
| 252 | +Cherry-picking is a Git operation that applies the changes introduced by a |
| 253 | +specific commit from one branch onto another branch without merging the entire |
| 254 | +branch history. Key points: |
| 255 | + |
| 256 | +* Purpose: move a single fix, feature, or change (identified by its commit SHA) |
| 257 | + from one line of development (e.g., from main branch) into another (in our |
| 258 | + case into a release branch) when you don’t want to merge all other commits. |
| 259 | + |
| 260 | +* How it works: Git copies the patch (diff) from the selected commit, attempts |
| 261 | + to apply it to the current branch, and creates a new commit with a new SHA on |
| 262 | + that branch. |
| 263 | + |
| 264 | +* Typical workflow: |
| 265 | + - Checkout the target branch (e.g., release/0.6.0). |
| 266 | + - Run `git cherry-pick` (or multiple SHAs). |
| 267 | + - Resolve any merge conflicts, then `git add` and `git cherry-pick --continue`. |
| 268 | + Test, review, and push the resulting commit into the release branch. |
| 269 | + |
| 270 | +NOTE: the cherry picking can be made in main -> release branch direction or |
| 271 | +vice versa. We prefer the first method when possible. |
| 272 | + |
| 273 | + |
| 274 | + |
| 275 | +## Git workflow |
| 276 | + |
| 277 | +### New release branch |
| 278 | + |
| 279 | +```bash |
| 280 | +# 1. Create release branch from the main branch |
| 281 | +git checkout -b release/1.2.0 main |
| 282 | + |
| 283 | +# 2. Update version number in build files |
| 284 | + |
| 285 | +# 3. Commit and push |
| 286 | +git commit -am "Prepare for 1.2.0 release" |
| 287 | +git push origin release/1.2.0 |
| 288 | + |
| 289 | +# 4. Tag the release |
| 290 | +git tag -a v1.2.0 -m "Release 1.2.0" |
| 291 | +git push origin v1.2.0 |
| 292 | + |
| 293 | +# 5. Merge into main (optional step) |
| 294 | +git checkout main && git merge release/1.2.0 |
| 295 | +``` |
| 296 | + |
| 297 | + |
| 298 | + |
| 299 | +### Update/fix existing release branch |
| 300 | + |
| 301 | +```bash |
| 302 | +# 1. Create branch from the release branch |
| 303 | +git checkout -b release/1.2.1 release/1.2.0 |
| 304 | + |
| 305 | +# 2. Update version number in build files |
| 306 | + |
| 307 | +# 3. Commit and push |
| 308 | +git commit -am "Prepare for 1.2.1 fix" |
| 309 | +git push origin release/1.2.1 |
| 310 | + |
| 311 | +# 4. Tag the release |
| 312 | +git tag -a v1.2.1 -m "Release 1.2.1" |
| 313 | +git push origin v1.2.1 |
| 314 | +``` |
| 315 | + |
| 316 | +NOTE: 1.2.0 and 1.2.1 are just examples, of course. |
0 commit comments