The other day I was touching up a PR that had been approved and was about to merge and deploy it when, out of habit, I checked the clock. It was 3:45pm, which for me, was past my "merge before" time of 3:30pm. I decided to hold off and wait until the next morning.
The whole process got me thinking. Does anyone else have their own personal merge or deploy policies? Is there a time before or after when you say, not today? Is there a day of the week you don't like to merge stuff. A lot of people joke about read-only Fridays, but I have to admit, I kinda follow that rule. Anything remotely high risk I wait until Monday to merge.
What's your personal merge/deploy policy?
Top comments (9)
If you're afraid to deploy you're doing something wrong. Deploying is like going to the gym, the more you do it the less it costs you. Tests and E2E integrations can help you to achieve more reliability. I understand that it's hard to risk your Friday, but if you have the habit it will be so easy.
This is definitely true, you do need to have confidence in your tests and policies so that eventually deploying is no big deal. We do continuous deployment, so usually we end up deploying anywhere from 10-15 times a day. Even though 99.9% of the time things go out without a hitch I still prefer not to deploy end of day, especially before I leave. I think it might be more that I feel guilty if something did go wrong and I wasn't immediately available.
I like both answers. I don't deploy last thing during the day or on fridays, but also feel a bit guilty that I don't fix process so that I can.
Also, I will never fully trust computers. I hear so often that a computer does exactly what you tell it to do, what it's programmed to do. But considering the complexity of computers it's often virtually impossible to determine what you've told them to do. So every now and then you tell them to do something that you have to tell them to undo.
Our corporate agreement is that, everybody can choose when to merge or deploy BUT has to be reachable by phone for at least three hours just in case his change broke something and the oncall rotation gets paged.
And, yes deployments and changes with a higher risk get are not common to go live on a friday.
Oh I like that 3hr policy!
I try not to deploy within an hour of when I need to be off for the day. If anything goes wrong and I need to deploy again, I don't want to be at my desk long.
Most of our deploys are pretty boring but you have to maintain a kind of policy regardless. You never know when some weird case kicks in.
It's hard to shake 15 years of "do. not. push. on. friday.", but... eh, all the service images are tagged. If something goes haywire, rollback to the previous tag and re-up. It's what... 5 minutes or so, and we'll clear it up on Monday.
I always deploy day's changes tomorrow morning 😎 If it's manual, not a hotfix and I have control over it then there is no point in rushing.
Proper CI, so the least amount of merging possible.