I have no problem with you or anyone else choosing not to deploy on a Friday. It's your life, you know your codebase and your production systems better than anyone else. Life is messy and imperfect.
But ...
If you're telling other people not to do it, as some sort of blanket rule, and think that it's an hilarious precondition of working as a developer... I find that really sad. We should be trying to make deployments delightful and easy so that they can happen at 5pm on a Friday without anyone worrying.
If you think that's impossible, I'd ask you to read around the subject and broaden your horizons.
Anxiety related to deploys is the single largest source of technical debt in many, many orgs. Technical debt, lest we forget, is not the same as “bad code”. Tech debt hurts your people.
Saying “don’t push to production” is a code smell. Hearing it once a month at unpredictable intervals is concerning. Hearing it EVERY WEEK for an ENTIRE DAY OF THE WEEK should be a heartstopper alarm. If you’ve been living under this policy you may be numb to its horror, but just because you’re used to hearing it doesn’t make it any less noxious.
If you’re used to hearing it and saying it on a weekly basis, you are afraid of your deploys and you should fix that.
Lead Developer, business owner, US Army veteran. I build things for the web. My website is a bunch of HTML pages that didn't need a framework. Yours can be too!
Yeah, I've always taken it as a given that internal business applications deploy on Friday evening, public (non-revenue generating) apps deploy on a Monday/Tuesday during the day, and public (revenue generating) apps deploy during lowest use.
"Don't deploy on Fridays" is honestly new (within the last 5 years) to me. We all know the danger is something goes wrong... but that's why you test it first.
If the internal app is messed-up, that gives you 2 days without users, and a strong incentive to get the PO to make the call on whether or not something is critical. If it's not critical, enjoy your weekend. If it is, yep, the team's working for the weekend. Then you REALLY need to retrospect on your testing practices, and how this critical flaw made it to prod.
If low usage occurs at 2AM EST on a revenue generator, then that's just when the deployment needs to happen. You better believe I've tested that thing into the ground, cause nobody wants to wake the whole team up for a problem.
I'm the last person to say it's OK to take developer's personal time, and the first one to say "let's try and avoid late nights" but sometimes the nature of the job calls for it, just like doctors and lawyers. The key is the employer recognizing it and arranging comp time, late starts, etc.
If you're afraid of deploying to production for any reason (not just anxious... everyone should have a little anxiety any time prod changes... it keeps us on our toes and away from the "Just push to prod, it'll be fine" mentality), then there's something off in the process that needs to be addressed.
Addendum: This is all assuming they aren't in a CI/CD environment... which many MANY places are not. A lot of places deploy at the end of a sprint, and God help you if you're in a monthly, bi-monthly or quarterly release shop. Again... the testing should be there to allay those fears though.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have no problem with you or anyone else choosing not to deploy on a Friday. It's your life, you know your codebase and your production systems better than anyone else. Life is messy and imperfect.
But ...
If you're telling other people not to do it, as some sort of blanket rule, and think that it's an hilarious precondition of working as a developer... I find that really sad. We should be trying to make deployments delightful and easy so that they can happen at 5pm on a Friday without anyone worrying.
If you think that's impossible, I'd ask you to read around the subject and broaden your horizons.
Here, this is Charity Majors, who explains it all better than I can.
(Charity is my hero)
Yeah, I've always taken it as a given that internal business applications deploy on Friday evening, public (non-revenue generating) apps deploy on a Monday/Tuesday during the day, and public (revenue generating) apps deploy during lowest use.
"Don't deploy on Fridays" is honestly new (within the last 5 years) to me. We all know the danger is something goes wrong... but that's why you test it first.
If the internal app is messed-up, that gives you 2 days without users, and a strong incentive to get the PO to make the call on whether or not something is critical. If it's not critical, enjoy your weekend. If it is, yep, the team's working for the weekend. Then you REALLY need to retrospect on your testing practices, and how this critical flaw made it to prod.
If low usage occurs at 2AM EST on a revenue generator, then that's just when the deployment needs to happen. You better believe I've tested that thing into the ground, cause nobody wants to wake the whole team up for a problem.
I'm the last person to say it's OK to take developer's personal time, and the first one to say "let's try and avoid late nights" but sometimes the nature of the job calls for it, just like doctors and lawyers. The key is the employer recognizing it and arranging comp time, late starts, etc.
If you're afraid of deploying to production for any reason (not just anxious... everyone should have a little anxiety any time prod changes... it keeps us on our toes and away from the "Just push to prod, it'll be fine" mentality), then there's something off in the process that needs to be addressed.
Addendum: This is all assuming they aren't in a CI/CD environment... which many MANY places are not. A lot of places deploy at the end of a sprint, and God help you if you're in a monthly, bi-monthly or quarterly release shop. Again... the testing should be there to allay those fears though.