
Ask HN: Do You Release on Fridays? - vidro3
How do you balance possible user downtime with developer work&#x2F;life balance?
======
matt_s
Nope. Every other work day at any time is fine. In fact multiple prod deploys
per day is perfectly fine.

Sometimes something has to be coordinated but we try to prevent that with
feature flags or putting "shims" of code in to bridge us from one workflow to
another and just remove the "shims" later.

Continuous integration plus small feature changes per 'ticket' and each item
can be deployed whenever it is ready. Ability to roll back a deploy in
minutes.

Occasionally if there is a fire or bug fix that needs to go out, those will go
on Fridays.

Who wants to be fretting all weekend about if something is going to blow up?

If you deploy on Fridays because of low user counts and there is some
unforeseen problem with actual users then you start your work week on Monday
with that problem.

------
lettergram
I support enterprises, it's actually easier to release on a Firday for us.
Typically, if we mess up it gives us the opportunity to fix the issue.

That being said, last time that happened was 18 months ago.

Most people don't work over the weekends so it's actually not too bad for us.

~~~
vidro3
how is Friday easier for you; fewer users?

Why not Thursday?

~~~
stevekemp
I think the point was that enterprise users probably don't work over weekends.
Of course that might be a bad assumption.

That way if something goes wrong on Friday you've got a weekend to fix it,
before the users come back on Monday.

------
kevinsimper
I release on Friday, it is not any different than any other day. Canary
deployment is the way to go and quick rollbacks makes your life easy

------
photonios
Yes. Friday is perfect. It's weekend in the country where we operate (United
Arab Emirates).

We're based in central Europe. So friday is a work day. Friday is weekend in
the UAE so there's usually less traffic.

If it the release/deploy doesn't work out, we roll back and try again the next
week. We make it a point to release small, reversible change sets.

Also, regardless of the day: deploy before 12:00. This is usually enough to
prevent release related work (or firefighting) from spoiling into personal
time.

------
Znafon
We do, we found that having a no releases on Friday policy was just an excuse
and diverting us from actually improving our CI/CD, monitoring and alerting
infrastructure.

We invested work on those and try to deploy as we can.

It works great for us but obviously you need to try and see what does for you.

------
CM30
Depends what you mean. On Friday in general? Sure, as long as you've got the
time to fix any issues that crop up, it's not the end of the world.

But companies I've worked for in the past have generally avoided releasing
anything after a certain time on a Friday. Usually, anything we want to
release that day needs to be out before 4pm or so, to give people time to
catch any issues that may crop up.

------
chrisked
Sure thing, but early in the day. That said we are a smaller team and very
conscious about the scope and QA. I guess we take calculated risks to not work
overtime into the weekend. Worked out so far quite well.

~~~
photonios
I've found that releasing early in the day really stops from interfering in
people's personal life. Usually after hitting the deploy button; there's a
couple of hours of checking, verifying and testing to make sure all is well.
By releasing early, you make sure all of that is done during normal work
hours.

+1

------
kull
Big releases - weekends only, usually Saturday morning. The least impact on
customers in case something goes wrong and you still have entire weekend to
roll back or fix, while not many may even notice.

------
thrower123
Hell no. Don't push to prod on Friday. Ideally, don't schedule any meetings on
Friday either.

During the summer, we rotate to give everybody every other Friday off, and the
rest of the time it's generally the policy to work from home Fridays unless
there is a really pressing reason not to.

This tends to allow a lot more real work to get done on Fridays than any other
day of the week.

------
LeonB
No, we avoid friday releases, as we aren't paid to provide weekend support.
Every second friday we dedicate to cleanup activities (which is a lot more fun
than it sounds, because we use it to improve parts of our stack, little things
that were bugging us)

------
codingdave
Depends on the Friday. We have official release windows on Wednesday, Friday,
and Saturday. So we could. And sometimes do. But mostly, we choose for each
release based on how big of a change it is, whether there are data migrations
that will take time, and whether the people involved in the change have plans
those nights.

------
Porthos9K
Hell no. We release on Wednesdays after business hours. If everything goes
well, then the developers get to bugger off early on Friday afternoon. It's
the only practical way to avoid working more than 40 hours a week unless it's
a literal _life or death_ emergency.

------
sergiotapia
Nope

There's no need and any pressing release is artificial. I schedule the
releases to go out at any time during the week, except Fridays. Fridays are
for heads down work, then some pair programming stuff for my engineering team.

------
taf2
Sure maybe Friday morning but not after lunch

------
staller
We release on Fridays, but approaching or after 4PM we ask ourselves "can it
wait till Monday?"

------
slipwalker
hopefully not. Most fridays are read-only, except for major bugs in
production.

So, a friday deploy means our test-suite has failed us...

------
CameronBarre
Hell no!

