Read on Twitter
Let me fix that for you.
"This is your reminder, that out of all the Fridays of the year, this is the one when you definitely shouldn't be writing code (unless it's a fucking emergency)." https://twitter.com/robocell/status/1342535113045848065
"This is your reminder, that out of all the Fridays of the year, this is the one when you definitely shouldn't be writing code (unless it's a fucking emergency)." https://twitter.com/robocell/status/1342535113045848065
It's not about pushing to production or not.
Frankly, even the phrase "pushing to production" reveals that your CI/CD pipeline is broken, because someone is in there doing manual "pushing".
It's about baking in the expectation that **if you merge code, it gets deployed**
Frankly, even the phrase "pushing to production" reveals that your CI/CD pipeline is broken, because someone is in there doing manual "pushing".
It's about baking in the expectation that **if you merge code, it gets deployed**
Why? Because code rots.
Think of it like food. There's an acceptable interval between when you prepare a nice hot dish and when you consume it. 15 minutes is fine, but it goes downhill fast. First it gets cold and clammy, then the microbes multiply. Days later is really too late
Think of it like food. There's an acceptable interval between when you prepare a nice hot dish and when you consume it. 15 minutes is fine, but it goes downhill fast. First it gets cold and clammy, then the microbes multiply. Days later is really too late
I totally, completely, 100% agree with people who are protesting against deploying on Christmas Day, or weekends, etc.
I'm just saying, back it up a step. Don't block deploys, block *merges* Don't fix the meal and let it rot; just don't fix the meal in the first place.
I'm just saying, back it up a step. Don't block deploys, block *merges* Don't fix the meal and let it rot; just don't fix the meal in the first place.
Which brings me to a topic I've been meaning to get to all month.
Holiday deploy freezes.
Holiday deploy freezes.
Holiday deploy freezes are like saving up all the food your teams are diligently preparing for two weeks, sans refrigerator, and dumping it all out on the table as a mouldering "feast" all at once come January.
The worst outages of my life have ALL been post holiday freeze.
The worst outages of my life have ALL been post holiday freeze.
This won't surprise you, but I think there is a better way. And no, I am not trying to behave as though Black Friday or xmas eve are just a day like any other day.
You know your product, your users, and your team far better than I do, and you should leverage that knowledge.
You know your product, your users, and your team far better than I do, and you should leverage that knowledge.
There are times in any company's year when the velocity of changes should slow to a trickle, when only "must fix" changes should be shipped, and all optional functionality put on hold.
This is just a fact. And it is not incompatible with my stance against deploy freezes.
This is just a fact. And it is not incompatible with my stance against deploy freezes.
What is the most important interval for reliability, resiliency and software lifecycle ownership?
If you've been listening to my rants over the past week or two, you'll remember this: it's the time elapsed between when you write the code, and when that code goes live.
If you've been listening to my rants over the past week or two, you'll remember this: it's the time elapsed between when you write the code, and when that code goes live.
It is fulfilling the promise of continuous delivery. Making it so that any engineer can assume, once they have merged their changes, the robots will take it from there and run tests and deploy to prod, ideally within 15min.
Get this right and so, so many things fall into place.
Get this right and so, so many things fall into place.
If you are someone who cares about these things, train yourself to think of everything that happens between "merge to main" and "is fully deployed" as an atomic operation. Then make it feel that way to everyone else, too. <3
With that in mind, how should we handle holidays?
With that in mind, how should we handle holidays?
If they're the high-traffic, "black friday" type holidays:
* tell people that only critical bug fixes or scaling fixes can be merged
* have an approval process, if you must
* ask people to work on things outside the critical path
* declare a feature freeze
* tell people that only critical bug fixes or scaling fixes can be merged
* have an approval process, if you must
* ask people to work on things outside the critical path
* declare a feature freeze
If they're the low-traffic, skeleton crew type holidays:
* encourage people to take real time off
* have a list of passion projects or prototype investigations for people to work on that don't involve critical components
* try not to make waves for a couple weeks
* encourage people to take real time off
* have a list of passion projects or prototype investigations for people to work on that don't involve critical components
* try not to make waves for a couple weeks
what you should NOT do, under any circumstances, is declare a deploy freeze, and encourage people to keep committing code and merging it to main, tho you will not deploy until after the freeze
... because you are busy cherry picking off branches and making a royal mess elsewhere
... because you are busy cherry picking off branches and making a royal mess elsewhere
Enlist your coworkers' good judgment. Be clear on the company goals over the duration of this special time period -- stability? minimum crew? all hands on deck for peak performance? -- and be clear on which diffs can be merged.
But if it gets merged, it goes out asap. Period.
But if it gets merged, it goes out asap. Period.
This would be a great time to make a resolution with your team, that by the end of 2021 you will have a functional CI/CD system that automatically deploys to production, with actual observability, and will never again live through the aftermath of a multi-week deploy freeze. :D
