Do you release on a Friday?

[simon_tomes]

Do you release on a Friday? (bonus points for sharing why)

• Yes
• No

[conrad.braam (conrad)]

I really want to understand why sprints end on a Friday, if teams typically don’t release on a Friday. I know that’s a deep-mind thing to be talking about on a Friday, but it’s been bugging me lately this entire sprint durations being rigid and all thing. Delivery should be when the software is ready, trying to deliver in sync with an external factor is #anti-fragile and anti-agile all at once in my mind unless there are ways to experiment and learn more.

A: For us the why is in the cost of a rollback, because some platforms do not support rollback, and require roll-forward by efficient design, we have to roll forward, and that requires getting creaky re-build uploads to happen quickly.

[stuthomas (Stuart Thomas)]

In my previous role, we did. We had systems that meant we had very high confidence in what we were deploying, and monitoring and alerting that empowered us to be able to respond (and rollback) quickly on the rare occasions that something went wrong.

[sebastian_solidwork (Sebastian Stautz)]

Yes and No, depending on the team (we are having 2 B2B customers for our product).

The No-team I’m on:
Our sprints end on Monday, Review and Retro in the afternoon, and Planning is on Tuesday.
The installation on the customer test server happens on Wednesday as it needs also some accompanying tasks.
The release in production is some weeks later either on Wednesday or Thursday evening.

The Yes-team I’m rarely working with:
The installation on test servers are more freely, can happen at any time.
But the installation in production is most times on Fridays, until End of Business. I don’t really know why.
Release dates are the last things being changed?

[alexschnapper (Alexander Schnapper)]

Can’t you change the sprint timing to switch spring change on Tuesday/Wednesday?

In our projects we communicate exactly also your points and some risks we can reduce why we have sprint changes inside the week (either Tuesday, Wednesday or Thursday).

[kato (Kat Obring)]

Solid CI/CD with automated tests means we have high confidence in what we’re deploying - and usually also releasing at that point.
If for some reason we’re twitchy we deploy and don’t release so we can observe what the code does in production (feature flags control who can see the deployed features).
On top of that a clear recovery process should prod incidents happen, and a pretty low lead time so we know we can get a fix out quickly.

[asprao78 (Srinivas Pavan Addanki)]

Sprints should usually end on a Tuesday or a Wednesday, or maybe Monday (if you need some catching up to do on the weekends).

But never on a Friday. The weekends mood catches up on Thursday itself. by Friday afternoon, the team is grumbling and keeps checking the time. The concentration levels are waning and everyone wants to leave the office and gather at the Pub.

[rosie (Rosie Sherry)]

Thank god @testingchef and I voted the same

[olly_f]

We’ve started releasing on Fridays at my work in the last 6 months. Or at least more regularly. It probably happens less than it could do because there are usually quite a few review meetings on Fridays meaning people don’t have much availability. We mostly build in quite small chunks so it’s generally low risk when we deploy, plus we can easily roll back changes. If it’s a bigger release with higher risk of things going wrong then we would just wait until the next Monday. I do not miss the days in a previous place of releases being done once a month in the early hours of Saturday and then having to do post deployment checks at about 7am on the Saturday.

[shad0wpuppet (Konstantin Sakhchinskiy)]

There are two schools of thought regarding releases on Fridays:

1. Releases on Friday are risky because if something goes wrong, it may be difficult to find and fix quickly due to the limited availability of team members over the weekend.
2. Releases on Friday can be beneficial because fewer users might be affected if an issue arises, but this is only relevant for apps with lower weekend activity. This allows time to address problems before peak usage times.

Personally, I prefer not to release on Fridays in all circumstances. But of course, there are cases where it is necessary, such as for critical fixes, patches, events, important business goals, etc

[pwicherski (Piotr Wicherski)]

Yeap. Mobile apps have their own rules here, I guess.

It is easier to release to small groups but with way longer approval/release times, with potential surprise by Apple, Samsung or Google’s false negative rejection.

Also, if we need to have it on Saturday, Sunday, Monday, or Tuesday because there’s an important “thing” that we need to support/improve/fix, then we need to release it on Friday at least.

It’s good to aim for Thursday in such situations, but yeah. Things happen and sometimes you need to release the next day.

[thanos_tzois (Thanasis Baltzois)]

Same as @pwicherski, we usually aim to release during the week but problems lead to release it on Friday

[alagrate (Shane Dennis)]

Technically, no. We release on Saturday and Sunday

Factory software, so downtime on the weekend for deployment and smoke testing means less chance of loss of manufacturing production.

[anders62 (Anders Wallin)]

Never. We release most of our products on Thursday, our products are not critical on a transaction level, we need quick feedback from users. And by releasing on thursday we have time to fix bugs before the weekend. Some few critical releases we do on the weekend. I have earlier, in other kind of enterprises seen all releases being done on weekends. But Friday - I see no point in releasing on that specific day

[clittlefair (Corry Littlefair)]

Whilst we are CI/CD we do not release on a Friday unless it is an emergency fix / urgent requirement.

The main reason - ‘If’ something does go wrong, we would not want to affect the team with regards to enjoying the weekend on fixing issues. (never rollback attitude).

But at the same time, we are ‘agile’ as much as we can be in our opinion, so if the business does see that things are not quite right, we want to be able to update and redeploy in order to keep them happy.

We define this as a quality gate since it also removes the ‘work faster’ attitude of getting it out before the weekend. Nothing worse than getting a load of test fail alerts on an evening or the weekend!

[alexanderontest (Alexander Oliveira Dunn)]

We deploy (almost) every change once merged.

As changes are small and our test automation gives confidence we only wait until the next day/ next week where there is a particular reason to take that change carefully.

[simon_tomes]

@pwicherski

with potential surprise by Apple, Samsung or Google’s false negative rejection.

Thanks for sharing, @pwicherski.

I think I know what you mean by this, yet would you mind expanding on “false negative rejection”?

At places where I’ve worked, app releases have been rejected because we forgot to include certain information, so the release itself was “fine” yet didn’t meet the admin requirements. Is that what you mean, or something else?

[mikeharris]

We practice continuous deployment and multiple times deploy every working day. It is so much easier to work in small batches than to make weekly or monthly releases

[sully (Sarah Sullivan)]

Yes - release is on Friday evening, 8 pm ET US. Why? It causes less disruption to customers to take the app down (internal app so customers are internal).
Sprints start/end on Tuesdays (why, I don’t know).

[conrad.braam (conrad)]

After writing this, it separately popped up as a topic on the ‘bird’ platform, and I’m keen to start a groundswell to allow us to move the ceremonies about somewhat now.