Code Freezes can have the opposite effect(jensrantil.github.io)
jensrantil.github.io
Code Freezes can have the opposite effect
https://jensrantil.github.io/posts/code-freeze/
4 comments
I cannot fathom why anyone would use a code freeze. Just create a branch at the commit you want to "freeze" and let dev teams keep working with their regular branches.
A code freeze is often a bad attempt at “fixing” a problem that should be resolved by feature freeze, controlled rollouts, and better testing.
Lived this many times. the worst part about these freezes is what happens right before the freeze - everyone will rush to push their changes prior to cutoff, which is exactly when you get the sloppiest commits. and then after the freeze lifts you get a flood of piled up changes all at once. Smaller, continuous deploys with a good rollback are way less risky than big batched releases after a freeze.
after the freeze lifts, you also have multiple contributors dumping large PRs at the same time, missing out on the progressive integration that happens otherwise. This makes it difficult to figure out the cause of regression (think bisect but with large commits).
Code freezes like this are worst when there is no individual branching capability or local revision control, because that guarantees large commits.
Code freezes like this are worst when there is no individual branching capability or local revision control, because that guarantees large commits.