DEV Community

loading...
Cover image for What's your personal merge/deploy policy?

What's your personal merge/deploy policy?

molly profile image Molly Struve (she/her) ・1 min read

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?

Discussion (10)

pic
Editor guide
Collapse
dviejopomata profile image
Dviejo

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.

Collapse
molly profile image
Molly Struve (she/her) Author

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.

Collapse
antero_nu profile image
Antero Karki

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.

Collapse
michafrombonn profile image
Michael K. • Edited

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.

Collapse
molly profile image
Molly Struve (she/her) Author

Oh I like that 3hr policy!

Collapse
ben profile image
Ben Halpern

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.

Collapse
therealkevinard profile image
Kevin Ard

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.

Collapse
dbanisimov profile image
Denis Anisimov

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.

Collapse
elmuerte profile image
Michiel Hendriks

Proper CI, so the least amount of merging possible.