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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
20 comments
[ 3.3 ms ] story [ 53.0 ms ] threadThat 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.
Why not Thursday?
That way if something goes wrong on Friday you've got a weekend to fix it, before the users come back on Monday.
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.
+1
So, a friday deploy means our test-suite has failed us...
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.
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.
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.
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.
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.