"Don't deploy on Friday" is a public admittance that your company either has no CI/CD pipeline, or that all your devs are retarded rhesus monkeys who only wipe their ass if the product manager wrote it as a spec.

If the saying was: "Don't port your whole API to GraphQL on a Friday", or "Don't switch from MySQL to Postgres on a Friday", I would agree.

But you should be able to do simple deploys all the time.

I deployed on Christmas & New Year's eve. I've deployed code while high on LSD, drunk-peeing 2 liters of beer against a tree after a party. I've deployed code from the hospital while my foot was being stitched up. On average, we deploy our main codebase about 194 times a week.

If you can't trust your deploys, maybe instead of posting stupid memes about not deploying on Fridays, you should fix your testing & QA procedures.

Worst thing you've seen another dev do? Long one, but has a happy ending.

Classic 'Dev deploys to production at 5:00PM on a Friday, and goes home.' story.

The web department was managed under the the Marketing department, so they were not required to adhere to any type of coding standards and for months we fought with them on logging. Pre-Splunk, we rolled our own logging/alerting solution and they hated being the #1 reason for phone calls/texts/emails every night.

Wanting to "get it done", 'Tony' decided to bypass the default logging and send himself an email if an exception occurred in his code.

At 5:00PM on a Friday, deploys, goes home.

Around 11:00AM on Sunday (a lot folks are still in church at this time), the VP of IS gets a call from the CEO (who does not go to church) about unable to log into his email. VP has to leave church..drive home and find out he cannot remote access the exchange server. He starts making other phone calls..forcing the entire networking department to drive in and get email back up (you can imagine not a group of happy people)

After some network-admin voodoo, by 12:00, they discover/fix the issue (know it was Tony's email that was the problem)

We find out Monday that not only did Tony deploy at 5:00 on a Friday, the deployment wasn't approved, had features no one asked for, wasn't checked into version control, and the exception during checkout cost the company over $50,000 in lost sales.

Was Tony fired? Noooo. The web is our cash cow and Tony was considered a top web developer (and he knew that), Tony decided to blame logging. While in the discovery meeting, Tony told the bosses that it wasn't his fault logging was so buggy and caused so many phone calls/texts/emails every night, if he had been trained properly, this problem could have been avoided.

Well, since I was responsible for logging, I was next in the hot seat.

For almost 30 minutes I listened to every terrible thing I had done to Tony ever since he started. I was a terrible mentor, I was mean, I was degrading, etc..etc.
Me: "Where is this coming from? I barely know Tony. We're not even in the same building. I met him once when he started, maybe saw him a couple of times in meetings."
Andrew: "Aren't you responsible for this logging fiasco?"
Me: "Good Lord no, why am I here?"
Andrew: "I'll rephrase so you'll understand, aren't you are responsible for the proper training of how developers log errors in their code? This disaster is clearly a consequence of your failure. What do you have to say for yourself?"
Me: "Nothing. Developers are responsible for their own choices. Tony made the choice to bypass our logging and send errors to himself, causing Exchange to lockup and losing sales."
Andrew: "A choice he made because he was not properly informed of the consequences? Again, that is a failure in the proper use of logging, and why you are here."
Me: "I'm done with this. Does John know I'm in here? How about you get John and you talk to him like that."
'John' was the department head at the time.
Andrew:"John, have you spoken to Tony?"
John: "Yes, and I'm very sorry and very disappointed. This won't happen again."
Me: "Um...What?"
John: "You know what. Did you even fucking talk to Tony? You just sit in your ivory tower and think your actions don't matter?"
Me: "Whoa!! What are you talking about!? My responsibility for logging stops with the work instructions. After that if Tony decides to do something else, that is on him."
John: "That is not how Tony tells it. He said he's been struggling with your logging system everyday since he's started and you've done nothing to help. This behavior ends today. We're a fucking team. Get off your damn high horse and help the little guy every once in a while."
Me: "I don't know what Tony has been telling you, but I barely know the guy. If he has been having trouble with the one line of code to log, this is the first I've heard of it."
John: "Like I said, this ends today. You are going to come up with a proper training class and learn to get out and talk to other people."

Over the next couple of weeks I become a powerpoint wizard and 'train' anyone/everyone on the proper use of logging. The one line of code to log. One line of code.

A friend 'Scott' sits close to Tony (I mean I do get out and know people) told me that Tony poured out the crocodile tears. Like cried and cried, apologizing, calling me everything but a kitchen sink,...etc. It was so bad, his manager 'Sally' was crying, her boss 'Andrew', was red in the face, when 'John' heard 'Sally' was crying, you can imagine the high levels of alpha-male 'gotta look like I'm protecting the females' hormones flowing.

Took almost another year, Tony released a change on a Friday, went home, web site crashed (losses were in the thousands of $ per minute this time), and Tony was not let back into the building on Monday (one of the best days of my life).

Had to wake four people up at 2 am to fix a crashing service.

10/10 would deploy to production on Friday night again.

Currently on an internship, PHP mostly, little bit of Python and the usual web stuff, and I just had the BEST FUCKING DAY EVER.

Wake up and find out I'm out of coffee, oh boy here we go.

Bus leaves 10 minutes late, great gonna miss my train.

Trains just don't wanna ride today, back in a bus I go, what's normally a 10 minute train travel is now a 90 minute bus ride.

Arrive at internship, coffee machine is broke, non problem, I'll just lose it slowly.

NOW HERE COMES THE FUCKING GOOD PART!!

Alright, so I'm working on a CMS that can be used just about on any device you want, mobile or desktop, it's huge, billion's of rows of scientific data. Very specific requirements and low error margins. Now, yesterday I was really enjoying myself here until today, Project manager walks in, comes to my desk and hands me a Samsung Gear S3, an Apple watch and some cheap knockoff. He tells me that before the Friday deploy, THE ENTIRE CMS SHOULD WORK ON THOSE WATCHES!

I mean, don't get me wrong, I like a challenge but it's just not right, I mean, I'm still not sure what the right way to handle tables on phones is, but smart watches, just no. Besides that, I've never worked with any Apple devices, let alone WatchOs, nor have I worked with Android Wear.

Also, Project Manager is a total dickhead, he's the kinda guy that prefers a light theme, doesn't clean up his code, writes 0 documentation for an API, 1 space = tab, pure horror.

So after almost flipping my desk, I just called my school coach to announce I'm leaving this internship. After a brief explanation he decides to come over, and guess what, according to the Project Manager I wasn't supposed to do that, I was supposed to test if it would be possible.

FUCKING ASSFUCKFACE

when you deploy on a friday

So I worked on getting a server ready for about 30 hours last week to be ready for a deploy on Monday Night (last night). Not only did I work on it for 30 hours, we had two other architects and a senior engineer working on it too. We got everything done Friday and it was ready to go with a simple cutover on Monday night.

The only thing left to do was deploy a link change Monday night on the existing landing page. My part was the backend servers and application that had the complicated SSO system and the other part was just a link to get to the SSO. I asked the person responsible for deploying the landing page's link if he was ready about a dozen times. He kept saying he was deploying X (the code name for the project deploy) and that is all he was doing.

Now jump to that night. They have decided that a single landing page wasn't enough and they were going to deploy a full CMS. Well no one knew what the hell was going on and they didn't realize that the landing page was hosted externally on another host. After arguing for two hours they delayed the deployment for multiple days. 24 hours later they are still trying to figure out the CMS on a host.

30 hours and four senior engineer's time wasted to get everything done for the deadline all to be canceled because of on jackass's lack of planning. WTF

*production is down*
Ops: At 5pm? On a Friday? *checks deploy history* God! Who did the deploy
Dev: It was a small patch, a tiny patch. It shouldn't have....
Ops: Deploy on a Friday evening?
Colleague: I didn't think it would...

Ops (on the outside) : *takes a deep breath* Its okay Dev, we can fix this. Don't worry

Me(in my mind) : for fuck sakes! Are you fucking kidding me?*** **** *** god damn it! *****

"Read-only Friday" rule: On Fridays, you don't deploy new versions, don't merge code into production, don't update databases, and a lot of others "DON'Ts"

Valve deployed a CS:GO update this Friday, guess what. It had quite a few bugs.

Never deploy on a Friday, please.

I had a huge epiphany on Friday... not all developers enjoy coding.

Discovered when they brought down 2 of our environments, well told them what was wrong with the changes in their code that caused the environments to break, gave them links directly to the file in the gitlab repo that needed to be updated, and...

They fucking went home. The change would’ve taken all of about 30-45 seconds to update and they fucking left.

This person’s team lead come storming in pissed off because her manager is furious about 2 environments going down and preventing everyone else from being able to deploy their changes.

We provide the exact same details to the team lead about what needs to be changed, and advise that her team member took off....

30 mins later, her manager is storming up to us (devops/sre) livid as hell.

Explain the situation for a third time... manager is like, why can’t you guys fix it?

Look here you dense motherfuckers, we can fix the code. We can be the plumbers that clean up your shit. But what value do you gain as a developer if you don’t understand how the systems work and you keep pushing shit in?

Made the changes, fixed the environments, done right? Wrong.

The original developer made more changes not knowing what would happen and thoroughly fucked the environments again.

This dumb-fucking dumpster fire of a dude then sends us a slack message. “It’s down again, can you fix it?”

Our manager steps in and tells us to send him a link to the logs and have him fix it himself!

Thank goodness we have a badass manager.

Send logs, send repo file links (again), and send line numbers in the logs to try and help just a bit more. Dude goes almost the whole day without fixing it, environments are down, other devs are pissed, we throw this dude to the wolves. His manager starts to head over and was about to talk with my team lead when our manager steps out of his office and tells him the in’s and out’s of the situation and that our job isn’t to play log parser/error fixer for the developers. This dude that’s breaking the environments needs to be the one to fix the issue and his team lead should be aware of the problems and should have been able to correct his errors before it ever came to us.

The amount of hand-holding we do is ridiculous.

(Disclaimer, this one guy making some mistakes doesn’t sound too bad, but this is actually a common occurrence for like 40% of all of our developers)

We literally have interns still in college running circles around some of our full time devs. I know I’m not a developer, but for anyone that’s new-ish to developing, when you see shit like that please don’t lose hope. Those ass-hats got into programming purely for a paycheck, not because of passion.

Stick with it and your greatness will know no bounds 👍

As for you craptastic dipstick lickers, FUCK YOU!!! Go back to school and learn how to give a damn.

We have a pretty simple rule in our team:

Do not deploy to production on Friday.

Well thanks to the client being very slow to reply to me, they only signed off on launching the app at 15:30 on Friday, for a big campaign the app was built to facilitate starting Saturday.

Guess who had to bite the bullet and launch a new app into production at 15:30 on Friday.

Guess who got a text from his boss at 19:30 that there was a critical change required tonight.

Guess who was making code changes and deploying to production at 21:15 on Friday night while drinking Gin and tonic...

Nb This was a project only i was assigned to and came in as a rush job at the last minute.

It's currently 11:21 pm were I am, and I just finished working

I decided to deploy on a Friday

Those two things are related

A support request came in at 4:30 this afternoon, I logged onto the server somewhat pissed off that there was a support request at this time on a Friday.

I checked the logs and noticed 500 errors coming from our integration parter after a little log checking and with glee I declared "not my fucking problem!" I replied to the customer and ccd our partner. Have fun bitches, next time deploy your new version when we fucking agreed!

Yuppie clients are utter cancer. You treat me like garbage, stress me the fuck out with constant calls and changes, and force me to deploy manually on a f*cking friday. Your site deserves to be broken. You deserve to be angry. I enjoy your business suffering, you yuppie ass money brabbing retardotron.

First rule that I learnt by being a DevOps intern - never deploy on a Friday.

deploying app 101: never deploy anything on a friday unless you want your saturday to be another monday

When your week has been so busy and exhausting you remember at 1PM Friday you have a deadline for Monday morning and force yourself to do a weeks worth of work in 4 hours and deploy it on a Friday without QA testing!

To future me - I apologise for Monday’s headaches.

The IT guy at client made a spaghetti code website to replace their time entry software. I come in to “finish it up in a week to two” (just me). I start by removing 1200+ lines of convoluted data access code that doesn’t work, SQL injection prone too. I quickly gave up and started from scratch; just copyied some of his actually decent HTML.

Friday, he proceeded to try to install node on the server and run main.JS. Now he’s all concerned my repo is too complex because he can’t deploy a static website 🙁

He didn’t ask me how it gets deployed nor did he listen when I said “node is NOT THE BACKEND we have .NET core for that”.🤦‍♂️

I’m gonna spend a week writing documentation at 5th grade level and hand holding him so he understands how this code works because he’s going to be the one maintaining it.

Don’t deploy on a Friday afternoon

When the CTO asks if you could do a "quick deploy" at 4.50 on a Friday

It's Friday afternoon sooo... let's deploy to production and go on vacation for a month. 😜

We were forced to do a Friday deploy of a new project. I, smartly, decided to bring my laptop with me on a "couples date". I spent the entire evening trying to fix a screwed up deploy from a restaurant.

Wife was NOT happy.

So i just saw a post about not pushing to production on Friday's and that reminded me of something.

A team we are working with (we needed help on something so we got another company to send us a team and do it for us) recently push to production on a Friday at around 5pm.

We didn't know that they had done it until a shit ton of errors started happening and we had no idea why (it was working so far, none of us did anything, so what the fuck is going on).

To make things better, one of my colleagues tried calling them and they wouldn't answer the phone. They knew what they did, so they went home before we could notice it and we had to correct their mistake.

We had everyone calling us saying they had gotten an error, and they needed to get home but couldn't because of it (it messed up a process that only happens at the end of the day before people go home. I can explain more in the comments if anyone is confused, or just wants to know).

Eventually everything was solved, but that was a very stressful ending of the week.

So yeah, don't deploy on Friday's please and thank you

So last week I really fucked up

I had this new implementation that was supposedly to be integrating smoothly into the rest of the service. It depended on a serialized model made by a data scientist. I test it in local, in QA environment: no problem.

So, Friday, 4pm, I decide to deploy to production. I check once from the app: the service throw an error. Panic attack, my chief is at my desk, we triy to understand what went wrong. I make calls with cUrls: no problem. Everything seems fine. I recheck from the app again: no problem.
We dedice to let it in prod, as the feature work. I go get some beers with the guys, to celebrate the deploy.

Fast-forward the next morning, 11am, my phone ring: it's a colleague of my chief. "Please check Slack, a client is trying to use the feature, it's broken"

FUUUUUUUUUUUUCK!!!

Panic attack again. I go to the computer, check the errors: two types of errors. One I can fix, the other from a missing package on the machine that the data guy used.

Needless to say, I had a fairly good weekend.

Lessons learned:
- make sure Dev, QA and Prod are exactly the same (use Ansible or Container)
- never deploy on a Friday afternoon if you don't have a quick way to revert

In horror movies. Characters do things that they them-self know it could kill them. Like getting in basement.

As a developer we all know to never deploy code on Friday. Here we are taking the wrong turn.

I may not be a dev... (learning in my off time though, best thing ever) but I have been responsible for the computer system validation, requirements definitions and planning of a new piece of software that will have a major increase in effeciency for a division consisiting of over half our companies employees.

For months it has been a painful process. I have had night terrors, immense pressure on my head all the while thinking we are getting to that final goal (live deployment), and the light at the end of the tunnel has just seemed to be getting further and further away... Like a donkey chasing a carrot on a stick.

After all the grey hairs, stress and drinking I am finally going to deploy this thing to the live environment tomorrow. Funny thing is its the part of this process that managers are stressing about and I am here like... Oh wow my Friday just got a whole lot better

Today I solved the problem assigned to me by changing one character. Simplest fix ever. Except that this problem is not on my project, and I don't have control over this project, so I can't merge my pull request or deploy the code, and the dev that does hasn't answered email today, and he's not scheduled out, and he's not in his office. Whatever, I'm just gonna say it's fuck it Friday and call it a week.

Here: this is BDD, a Linter, and Git. CI your shit to staging before you CI to production. Never deploy on a Friday.

We deploy the website of a client today. On the 13th Friday. Before weekend. Before I fly abroad for my holiday. If anything goes wrong I'm planning to secretly run away.

It feels like it's time for my first rant.

Sitting here in the office, it's 1 a.m. right now.
I knew i shouldn't deploy my project on a friday, but the deadline is sunday, so otherwise i would have been f*cked.
Anybody feeling with me?

Deploy framework upgrade on a Friday? Nope nope nope!

How to impress PM:
1. Prepare a critical bug, that makes the frontend crash
2. Prepare a hotfix, that fixes the bug
3. Deploy bug on Friday afternoon
4. Wait until PM starts panicking
5. Deploy hotfix after 5 min
6. Get praise from PM

I was thinking about the problems one of our clients faced with the launch of their project the other day, because things were rushed, stuff was omitted and in the end they could not meet the launch date, and I started making a list of hard lessons I learned over the years that would have helped them avoid this situation.

Feel free to add yours in the comments.

- Never deploy on Friday
- Never make infrastructure changes right before a launch
- Always have backups. Always!
- Version control is never optional
- A missed deadline is better than a failed launch
- If everything is urgent, nothing is important
- Fast and cheap, cheap and quality, quality and fast. Only one pair at a time can be achieved
- Never rush the start or the end of a project
- Stability is always better that speed
- Make technical decisions based on the needs of the project two years from now
- Code like you will be the only maintainor of the project two years from now. You probably will...
- Always test before you deploy
- You can never have too many backups (see above)
- Code without documentation is a tool without instructions
- Free or famous does not necessarily mean useful or good
- If you need multiple sentences to explain a method, you should probably refactor
- If your logic is checked beforehand, writing the code becomes way easier
- Never assume you understand a request the first time around. Always follow up and confirm

There are many more that should be on this list, but this is what came to mind now.

A top food chain client wants a feature Fx
and has a deadline on Friday.
We are still working on it and already estimated hours and set deployment on Monday.
(No deployments on Friday)
And the business/sales guy comes up with new deadline to submit it at Friday morning.
And was only discussing with one of my team member already working on it. And i knew there is more hours required for testing and need to deployment pre deployment phase (staging of dev)
I was over hearing the conversation between them and I got pissed off and jumped in and said Not Possible at all.

He tries to argues about giving something to him. I said we can give it to you but will not garauntee anything. Now project manager jumps in. PM and my team already know that we will be delivering on Monday.

He arguing that if the Fx is not ready then I will call client developer to office to test it directly on my team members laptop.
I said, No way. We are not ready yet and havent finished yet. Major work will be on Thursday and on Friday we will be testing till end of the day.

PM explains him blah blah stuff.
He calms down and says no worries we will check the status on Friday afternoon amd roll out something to Client.
PM, developer and I looked each other and I said, sure will deploy but will not garauntee anything. He goes back to his desk.

Seriously.
WE ALREADY ESTIMATED F* MAN HOURS AND WILL BE READY ON MONDAY MEANS MONDAY DONT F* BUILD MORE PRESSURE ON US. F* SALES

!Rant

Tldr: great spike to solve deployment problem may be a wasted effort.

Deployments of an ancient electron application need to be done in CodeDeploy to deploy the latest build. Customer hour restrictions cause this to be done only after midnight, and manually checked.

The whole team knows this is the wrong method of deployment and that there are many other operational problems with the project.

A few other senior team members get together and decide to spike out a way to use electron auto-deployment to accomplish this without using code-deploy at all.

After a shallow dive into this subject, we all get pulled aside to handle a change in another part of the software ecosystem. It happens. We leave the spike behind.

A junior-intermediate developer on the team pics the project up and gets a good spike going in a day and a half! We are all high fives and beers. This is Friday.

By Monday there is a pull request in for code review and it looks solid. Seems like it will make deployments a lot better.

Preparing the last deployment (hopefully) with CodeDeploy ever...

Marketing team members inform us that they are running an add system on the customer devices and to do it they are using Linux.

The current application being deployed is using Windows 10 (yeah, another problem).

They say they have made plans to move our application over to Linux. This means we may not be able to launch the junior devs great spike and the old deployment method may stay for the time being.

Meetings soon to find out how all of this will hash out.

End of rant. I hope I'm doing this right

Soo, lets talk about deadlines and how often I come in trouble when there is one near. This week I have (had) three. So I had a lot of problems this week.

But, after all today was a really good day.

I deleted an production database, fucked up my laravel migrations and tomorrow we have to deploy another application. The app is still in development and the site isn´t finished yet.

Friday I need to launch another webapplication. Because I don't want to deploy webapps and apps on friday and I go snowboarding next week, I somehow convinced my client to launch it next week. He agreed with me, so that's a burden off my shoulder. And I'll have an extra day for fixing the last bugs.

Today I worked really hard and almost finished the last application. So I think after all I'll somehow manage it.

There is a serious possibility that our team will need to deploy into prod on a Friday because of a regulatory deadline and 3rd parties not being ready.

God help us

Who the twattrumpet invented friday deploy was a good idea? What not who the horsedesecrating dickbadger tought I will have overdue work because this disgraceful human rudiment who has embryonic fluid inside his puffball head instead of brain thinks it is okay tell me sorry man but I forgot to tell you about the bugs you requested for last week. You know what? I will do it but if you dare to disturb me on weekend becausebyou didn't test whenbI told you I will stick your carcass up your ass!!!

Every first of a month is our most intense day because we have the most data throughput then due to lazy people we get data from. And boy will it be even more intense when something broke because we were forced to deploy a new feature the day before...