28 ms·

> Versioning/release/deploy/rollback is dealt with mostly outside of git, or with tags-on-main at most. This is simply outright wrong. Releases are not a tagge

by rewmie 3y ago

> Versioning/release/deploy/rollback is dealt with mostly outside of git, or with tags-on-main at most. This is simply outright wrong. Releases are not a tagged versions of a development branch. There is stuff that belongs in releases but should not be present ever in develop branches at all, and vice-versa. Once you need specific changes going into a release, you need branches. Also, you should not block development work on the development branch just because you need to push a release. Also, if you find a bug in a release candidate, you fix that bug alone. You do not add other changes just because someone committed them to the development branch. Cutting a release means picking up an unstable version and work your way up to make it stable. This means freezing the introduction of additional random features, and commit bugfixes only. Tagging does not allow that.

the_gipsy 3y ago
> Once you need specific changes going into a release, you need branches. I don't have this need. Then I don't need to deal with the sheer insanity of loosely spreading all those different git refs you mention over everything including the future. Changes get integrated fast into main, because nothing is blocked, frozen, or left for someone else in the future. This also makes commits/PRs/changes small. Feature flags are used to ease this even more. In the face of absolute disaster it is possible to simply revert/rollback a release/deploy. However in practice I don't really need to do this, almost never. Some hotfix here and there maybe, but it's still all much faster than the sheer insanity of git-flow overcomplications. Often a hotfix is the only solution, a revert/rollback fixes nothing when the problem is outside of git (DBs, client storage...). In the end, you have to evaluate all the time you sink into this model, and how much risk you actually mitigate. Wherever I've seen git-flow, the overhead was huge and ever-growing, and it never really helped with any risk mitigation. I would go as far as saying that overall it increased the risk, due to its complexity.
WorldMaker 3y ago
> There is stuff that belongs in releases but should not be present ever in develop branches at all, and vice-versa. Divergence between development branches and release branches may be a sign of stuff that should be configuration-only/environment-configurable and outside of source control. "Build-once, run-everywhere" is a useful mantra: once a version has been cut, if it can be built once and only once and run in every development or release environment, you know that you are stably testing the same build artifacts in your QA environments that you will eventually release. > Also, if you find a bug in a release candidate, you fix that bug alone. You do not add other changes just because someone committed them to the development branch. If you are marking your released versions with git tags then you just build a short-lived branch from the release candidate tag, PR the fix to the short-lived branch (and any long term changes to the main/trunk branch), and cut the bug fix version from the short-lived branch (tag the new version). You don't need long-lived release branches to bug fix older versions and releases.

by rewmie 3y ago

the_gipsy 3y ago

> Once you need specific changes going into a release, you need branches. I don't have this need. Then I don't need to deal with the sheer insanity of loosely spreading all those different git refs you mention over everything including the future. Changes get integrated fast into main, because nothing is blocked, frozen, or left for someone else in the future. This also makes commits/PRs/changes small. Feature flags are used to ease this even more. In the face of absolute disaster it is possible to simply revert/rollback a release/deploy. However in practice I don't really need to do this, almost never. Some hotfix here and there maybe, but it's still all much faster than the sheer insanity of git-flow overcomplications. Often a hotfix is the only solution, a revert/rollback fixes nothing when the problem is outside of git (DBs, client storage...). In the end, you have to evaluate all the time you sink into this model, and how much risk you actually mitigate. Wherever I've seen git-flow, the overhead was huge and ever-growing, and it never really helped with any risk mitigation. I would go as far as saying that overall it increased the risk, due to its complexity.

WorldMaker 3y ago

> There is stuff that belongs in releases but should not be present ever in develop branches at all, and vice-versa. Divergence between development branches and release branches may be a sign of stuff that should be configuration-only/environment-configurable and outside of source control. "Build-once, run-everywhere" is a useful mantra: once a version has been cut, if it can be built once and only once and run in every development or release environment, you know that you are stably testing the same build artifacts in your QA environments that you will eventually release. > Also, if you find a bug in a release candidate, you fix that bug alone. You do not add other changes just because someone committed them to the development branch. If you are marking your released versions with git tags then you just build a short-lived branch from the release candidate tag, PR the fix to the short-lived branch (and any long term changes to the main/trunk branch), and cut the bug fix version from the short-lived branch (tag the new version). You don't need long-lived release branches to bug fix older versions and releases.