Timeline for Branching model for nightly deploys
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 16, 2020 at 22:17 | comment | added | Alex Ball | I think this explains my current idea best: medium.com/@sairamkrish/… | |
| Apr 16, 2020 at 21:52 | comment | added | Alex Ball | Makes sense. This may be more of a people problem, but UAT delay for any particular issue would run the risk of either delaying the release branch cut, or introducing bad code into the release branch. While we work to improve automated testing coverage and reduce reliance on UAT, I'd lean toward a topic-branch-based paradigm, where topics are individually promoted to a UAT branch/environment and later to master, rather than scheduled release branch cuts, so that only accepted topics make it to master. We don't quite have enough test coverage to make me comfortable with full TBD, either :( | |
| Apr 16, 2020 at 21:07 | comment | added | taleodor | > what happens if a change in a release branch is declined or deemed to need extensive revision -- Ideally, you don't change release branch at all apart from critical (i.e. security) fixes. So you do all your testing before cutting release branch. | |
| Apr 16, 2020 at 20:21 | comment | added | Alex Ball | Thanks! I think GitFlow would be a little too cumbersome for nightly deploys, especially with an eye toward CD. Cutting release branches in a TBD-based model might make sense for less frequent deploys, but it doesn't address well the question of UAT (QA) rejection—what happens if a change in a release branch is declined or deemed to need extensive revision? I'm envisioning something in the middle, more like gitworkflow: github.com/rocketraman/gitworkflow which would allow us to integrate branches on master only if they pass UAT, with a throwaway environment for QA. | |
| Apr 14, 2020 at 1:10 | history | answered | taleodor | CC BY-SA 4.0 |