We do not deploy on Fridays, AmIRite?

Ah, the infamous Friday Freeze – a term that became somewhat of running joke among developers. The idea is simple: Don’t deploy on Fridays. Why? Because if something goes wrong, your weekend plans might just go up in smoke as you scramble to fix the emergency. So instead of putting energy and effort into developing and fostering a deployment process we can trust, we focus on avoiding potential disasters. Sounds like a stressful environment if you ask me.

It’s not about Friday. It’s about fear.

We don’t deploy on fridays, if we don’t trust our software and/or our process. So, what if, instead of hiding behind programmer-memes and perpetuating the false narrative of No friday deploys we fix the underlying issue and deploy software, that is proven and tested and deployed in an automated manner?

I know, strange thinking here 🤭

But let’s be real for a moment: Is the Friday Freeze really a good practice? Spoiler alert: It is not. In fact, it can be quite counterproductive.

Disadvantages of Friday Freeze

First off, avoiding deployments on Fridays will inevitably create a bottleneck. If everyone is tries to deploy their changes earlier in the week, it can lead to rushed and poorly (if even) tested deployments. This rush can actually increase the likelihood of errors (both in a broken software and as in impacting other systems), which is exactly what we’re trying to avoid in the first place. Plus, if something does go wrong mid-week, it can still spill over into the weekend. So, the Friday Freeze doesn’t really save us from weekend work; it just shifts the risk to other days.

And then there’s the YOLO-deploy. You know, the “You Only Live Once” approach where you throw caution to the wind and deploy without giving any f*cks. (While there are days, where I seriously run out of all the f *cks I could give, it’s still not exactly the best strategy for maintaining a stable production environment.)YOLO-deploys can lead to unexpected issues and lots of firefighting. (And firefighting during the weekend means that I don’t get the rest I need 🙄).

Having developers literally throw their software over a fence and then keep fingers cross to hope for the best has never been a valid approach, and still I hear lots of things at customers that make me ~scratch my head~ wanna cry:

Deployments? I thought this is low-code! We just right-click and publish.

Or even:

Testing? Our end users will mention if something doesn’t work 🤞

While these beliefs might seem convenient, they are far from good practice.

Just because it’s low-code, doesn’t mean we can skip proper deployment habits. Low-code platforms like Power Platform still require structured deployment pipelines to ensure stability and consistency. The infamous argument: Yeah we only do this for small changes! - Trust me - there are in fact no small changes, so please do yourself and your team a favor and don’t even think about publishing what you deem a small change without pushing the change through the pipeline.

Relying on end users to catch issues? That’s a recipe for disaster. End users are great at providing feedback, but they shouldn’t be your primary line of defense. Proper testing, both automated and manual, is crucial to catch issues before they reach production. Automated tests help ensure that your application works as expected. But even if you covered your bases in terms of automated tests: Manual exploratory testing is also important to catch those unknown unknowns that automated tests might miss.

So, shall we revisit how we think about deployments instead of a rigorous Don’t deploy on Fridays or anyday YOLO deploys? I think it’s about time to do so! Here are a few tips:

Automated Testing - More is more!

Automated testing is your best friend when it comes to catching issues early. Think of it as your safety net. By implementing comprehensive automated tests, you can ensure that your code is functioning as expected before it even hits production. This includes

• unit tests, which check individual components
• integration tests, which ensure that different parts of your application work together
• and end-to-end tests, which simulate real user scenarios
• performance validation, which measures how speedy operations are being completed
• security tests
• accessibility tests

The more you test, the more confident you can be in your deployment - regardless of the day of the week!

Continuous Integration and Continuous Deployment (CI/CD)

CI/CD pipelines are the backbone of deployment practices. By adopting CI/CD, you automate the deployment process, ensuring that deployments are consistent and repeatable. This reduces the chance of human error (and yet again: We ALL make mistakes!) and allows you to deploy changes more frequently and reliably. There are lots of options to do this properly in Power Platform, and I’ll cover this topic in the next part of this series. Stay tuned!

Monitoring and Alerts

Setting up robust monitoring and alerting systems is crucial for maintaining the health of your application post-deployment. These systems make sure that you are the first to know if something went wrong - instead of your users noticing it and calling the emergency hotline (which seems to be your mobile on a weekend). I’ll blog about how to monitor your Power Platform solutions in another post of this series.

Rollback Plan

Always have a rollback plan in place. If something does go wrong (and it will!), you should be able to revert to the previous stable state quickly and efficiently. If you need to figure out how to roll back only when you need to, you will loose time (and get some extra grey hair).

Conclusion

Yes, deploy (also) on Fridays! Don’t fear the weekday, but fear non-tested software and a poor deployment process. If you feel like “Yeah, we should probably invest into creating or solidifying our CI/CD process BUT WE JUST DON’T HAVE TIME” - then sorry to break it to you, but you are confusing cause and effect. Having even a basic testing routine and pipeline will not only make sure, that you will more often smaller changes (which reduces likelihood of BIG things to break), but also reduce the time you need to spend on every single deployment while ensuring easy revertability. You know, just in case something goes wrong :-)

This post is the first part of a series about good development and deployment practices. Stay tuned for the next parts where I focus on

• How to use Azure DevOps to deploy Power Platform projects
• How to test Power Platform solutions
• How to monitor Power Platform solutions with Azure Application Insights

Let me know if you have questions :-)