Code Freezes are great, but post Code Freeze times can be a bit rough in a large org as everyone rushes to get their code through.
If you've overcome this (even partially), what would you recommend for someone who is aiming to do the same?
If you've overcome this (even partially), what would you recommend for someone who is aiming to do the same?
Comments
Merge freezes: problem when everyone tries to merge their PRs at the same time
Deploy/prod freezes: easier to manage when there is an internal deploy/preprod -> almost client impact
But such system is harder to setup 😅
A system that actually works are deployment freezes. They allow people to still commit, integrate, and test while maintaining user stability over the holidays.
Deployment Freezes, on the other hand, can be a band-aid for having incomplete test coverage & should be as short as possible
Devs need to work around it and deal with the stress of the commits everyone wants to push at once after.
Even with lower env they can only go so far unfortunately before waiting for freeze to end due to dependencies.
Totally agree on automated testing tho!
“Code freeze” is a symptom of a process that’s coupled merges with deployments with releases.
Code should be promoted through each stage with confidence, not arbitrarily stopped because there aren’t enough controls in place.
They need to be treated as an emergency stop cord. Routine use of them is a symptom of bigger issues.
If it’s merge hell logistics then that’s a slightly different answer.
If it’s about confidence in so many changes rolling out then default feature flagging stuff that’s cued up can help.
Anything that would otherwise be merged when the freeze ends has already worked out merge issues etc on that branch.
The benefit is it leaves main open in case you bypass for a prod bug.
+1
If you’ve remote hosted dev, qa, sandbox, etc env’s it should all be good
*Note: we have a microservice architecture so changes are isolated to individual services which minimizes the coordination required
PR merged in can cause issues for hotfixes, and not merged in lead to them sitting there for ages and getting them in causes issues.
Long running feature branches have downstream issues almost as bad as a bunch of code merged but undeployed.
Keep the window short, encourage avoiding big changes, and get buy in around why.
Easy peasy.
Holiday breaks are a perfectly reasonable time to deploy freeze to give actual humans a break from heavy prod support.
Probably also good to communicate w/ business there needs to be chill & thaw periods around the freeze to let things come in slowly and not rush everything in
Reducing the number of PRs against the main branch tremendously reduces complex merges and unforeseen conflicts.
The clients/customers we serve still tend to be early in the transition away from a more waterfall cadence of planning and generally the freeze is built into schedule so there really isn’t a rush.