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.
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.
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.
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.