Everything to Know About “No Deploy Fridays”

We get it: your team doesn’t like the potential idea of spending their weekend patching over the really bad bug that somehow didn’t get caught during the last quality assurance check. 

And yeah, it’s easy for your team to want to hold off on deploying on Fridays because, well, it gives you a whole extra day after Thursday to patch up any issues. How great, right? With a clear, carefree weekend ahead, your developers are obviously going to be so much less stressed knowing they’ve got a solid piece of software out the door, right?

Maybe not. 

Not deploying on Fridays can seem to have some pretty clear benefits, but it also comes with some big negatives. We’ve put together some insights on why you should possibly think twice about practicing “No Deploy Fridays.”

• What does “No Deploy Fridays” mean? 
• Why can “No Deploy Fridays” be dangerous? 
• Reasons you’re afraid to push to production 
• Alternatives to “No Deploy Fridays”
• How to build a healthy deploy culture 

What does “No Deploy Fridays” mean? 

“No Deploy Fridays” means quite literally what you think it would: no code gets deployed on Friday—not in the morning, and most certainly not in the afternoon; not on the Friday before someone’s vacation, mini getaway trip, or regular weekend; no Friday ever. 

The concept has been swirling around the developer community for the past few years. It’s typically considered a healthy practice for mature IT teams that have built great processes and can afford to plan the rest of their week, so code deployments don’t land at the end of the week. Instead, the purpose is to deploy earlier in the week and provide the development team with enough working days to identify and patch bugs before their days of rest.

Build a culture of effective meetings with your engineering team

Level up your engineering meeting habits to boost engagement and productivity with a collaborative meeting agenda. Try a tool like Fellow!

Try Fellow for free

Why can “No Deploy Fridays” be dangerous?

Restricting your development team from deploying on Friday can have some serious impacts. For one, doing so fosters a fearful mindset that every deployment is likely to come with massive bugs that could critically affect the function of the software. Anxiety rises, and developers lose motivation to take educated risks in their work. Over time, this fear consumes the team and builds a toxic culture surrounding the way software releases are managed. 

Additionally, not deploying on Fridays forces teams to get work done earlier in the week, even if it’s not quite feasible. This leads to rushed projects, which can actually introduce more vulnerabilities and bugs than if the team took its time and used the day on Friday to do the last round of quality assurance before deployment.

Reasons you’re afraid to push to production 

• Frequent deploy breaks
• Insufficient testing 
• Long feedback loops 

1Frequent deploy breaks

If your production environment is continuously breaking, it’s fair that you might be worried about it anytime you go to deploy. Deploying is especially risky when you’re launching major feature changes or a lot of code at once. As well, this risk can be increased when you’re working with too many tools that are overloading your systems and not allowing your teams to stay in sync—hint: great continuous integration/continuous delivery (CI/CD) tools can help!

2Insufficient testing 

If you haven’t integrated a thorough quality assurance testing routine into your software development life cycle, it’s about time you do so. Depending on the size and complexity of your application, you might consider having multiple people review the code before it hits production; this way, you maximize the number of fresh eyes who can check for bugs. While you’re at it, practicing regular security testing can also help you identify new vulnerabilities and ensure that your new code doesn’t include any security threats that could negatively impact your business.

3Long feedback loops 

Long feedback loops are a symptom of a disorganized development team. Often, alongside your long feedback loop, you also have less structure and process to guide your team on what to do and when to do it. Part of the reason might also be if you have broken or unsupported communication channels for your team. Providing clear communication channels and structure relating to when feedback needs to be delivered can help your team feel more confident about deploying new code.

Alternatives to “No Deploy Fridays”

• Ship fast, ship often 
• Don’t ship right before end of day
• Have hotfixes ready
• Look once it’s live

1Ship fast, ship often 

Shipping smaller batches of code more frequently will help minimize the fears that come with deploying new code. Rather than waiting all week to deploy everything at once, consider releasing once a day (or even multiple times a day if you can). As soon as you have code developed and approved by your quality assurance team, the code should be deployed. Smaller, more frequent deployments allow your team to catch bugs sooner and manage them in smaller quantities. Shipping smaller batches of code more frequently also decrease the risk of your production environment crashing.

2Don’t ship right before end of day

Don’t wait until 4:55 pm to ship that code! 

Make a good practice of deploying your code well before the workday is over so your team has enough time to stay online and figure out a solution if something goes awry. If your team is working across multiple time zones, it’s important to communicate when everyone’s end-of-work time is so you’re confident you have support for a few hours following the deployment. 

Many studies suggest that our brains are most awake and creative in the morning, so this could be a great time to do the last quality assurance round with a fresh mind and then deploy early. Creativity will come in handy if you need to patch an issue!

3Have hotfixes ready

Thinking proactively about what could go wrong is an amazing step toward ensuring your launch goes as smoothly as possible. Knowing what to look for and how to prepare for building hotfixes for your particular software will take some time, experience, and maturity in your development team. However, there are a lot of best practices around hotfixes that can help your team get there sooner. 

4Look once it’s live 

Don’t wait until users report issues. By that time, it’s likely that a lot more than one user has been affected (and this is especially true as your user base grows). Even worse, if the bug is critically affecting the function of the application, you risk losing existing and future customers—in turn, this affects your company’s revenue and reputation.

Save yourself the stress and do a quick quality assurance test on the production environment after the new deployment is live. Better yet, have multiple people test on all various compatible devices on which your software works. This way, you ensure you have a thorough test of the new live code.

How to build a healthy deploy culture 

• Create a deploy philosophy
• Have a DRI 
• Check on your deploy 
• Practice good deploy hygiene 

1Create a deploy philosophy

Building a philosophy for your deployments is a practice most commonly adopted by teams that already have strong DevOps processes. Having a deploy philosophy means establishing a collaborative approach to software launches to ensure you’re fully covered on all tasks and aligned on goals for your launch. Better yet, this approach can also be extended into DevSecOps practices which consider your application security as well!

2Have a DRI 

Your team’s directly responsible individuals (DRI) in software development life cycles are critical to an efficient deployment that doesn’t have any overlooked elements. Essentially, everyone will have very clear instructions on how they contribute to the project. It can also be helpful to document these roles and responsibilities in a shared document. As your team gets used to this process, it might be helpful to keep the same person responsible for the same elements for the first few cycles. Later, team members can take turns getting experience with different elements each cycle.

3Check on your deploy 

Even though you’re shipping fast and often, you should be careful with your deploy. Take it slow, and be thorough with your testing. This means even if you’re launching code every day, you want to be sure that you have enough sets of eyes on each stage of the deployment. Document checks where needed, especially when working on larger or more important releases. 

4Practice good deploy hygiene 

As you deploy, there are many things you can do to make the process easier. For example, integrating the use of feature flags can enable your team to make changes to the deploy without requiring additional code. This minimizes your risk of it all going downhill when it hits production. 

Additionally, you really want to encourage your team to be proactive, stay in communication, and not be afraid to call out if something doesn’t look quite right. The earlier you can get to a bug, the less negative impact there is on the customer (and business!). As well, it means you can get to a patch earlier! 

Parting advice

There’s definitely something to be said about the comfort that comes from not deploying right before your time off. However, the practice of “No Deploy Fridays” can actually be harmful to your team’s ability to create code that is not rushed or built in fear of all the what-ifs that happen after deployment. Instead, focus on building a structured process to ship code more frequently, in smaller batches, and with strong testing and feedback processes in place. This will help drive the development of more innovative, secure, and bug-free code to really impress your user base!