DEV Community

Nimmo
Nimmo

Posted on • Edited on

Deploy every Friday

Every Friday I see people on Twitter shouting about how it's #noDeployFriday. And every Friday, I deploy to production anyway.

Do I hate quiet weekends? Not at all. I moved to full continuous deployment because I wanted quiet days, evenings, and weekends.

I got here by moving to continuous deployment.

I once worked for a company that had a painful release cycle. Everything had to stop once a month, and everyone spent the period immediately afterwards fixing issues.

Once I was in a position to own my own team's pipelines I wanted things to be better.

I started out with continuous integration (CI). Every change that we made was automatically tested and compiled, and the team was automatically notified of the build result.

This saved the team a lot of time, but I wanted more.

Moving to continuous deployment (CD)

How could I be sure that everything was ready to go to production all the time? My work could be categorised in two ways:

1: Changes to pages that were already available to users

Feature flags were enough to ensure that these changes didn't prematurely become accessible to users.

2: Changes to pages that weren't yet available to users

I decided to extend this idea a little further here. I already had a mechanism in the application to denote available pages, so I extended that to enable/disable entire pages easily based on the user's environment.

A function that returns true or false based on which page is loaded in combination with an environment type

Now I had everything I needed to turn on automatic deployments.

And everyone lived happily ever after, right?

Well, sort of. There were a couple of things that we hadn't quite accounted for:

1: You can still make mistakes, but now your users can see them

It only took one bug to accidentally put a page live. This taught me that I needed an extra safeguard.

I added automated tests to check the status of each page. This meant a small overhead when making a new page available to users, but eliminated the possibility of users accessing pages before they were ready.

2: Caches can trip you up sometimes

My application is being served by AWS Cloudfront, which is known to cache aggressively. I initially invalidated this cache manually, but this wasn't good enough after moving to CD. This was easily fixed by amending the pipeline to invalidate the cache every time it ran.

I deployed over 70 times last week alone without worrying how close it was to 5pm, or what day it was. It's scary to begin with, but it's worth it.

"#NoDeployFridays"? No thanks.

Things mentioned in this post

Feature flags

Top comments (0)