Friends don't let friends right-click publish

I've been throwing out this little one-liner for years and it seems to have resonated with some people. So much so that I made a sticker!

Friends don't let friends sticker

If you want one of these stickers, well... it's a bit harder than in the before-times when people went places. But ping me on Twitter. I'll see what I can do.

Cool, cool, but what does it mean?

Great question. Glad you asked.

"Right-click publish" refers to the really, really, really, super common practice of publishing your web application to Azure directly from Visual Studio. It's a really popular technique used by developers everywhere... and far too frequently by Microsoft presenters on stage.

Right-click publish in VS

This is an awesome way to deploy your web application to Azure.
To try it out.
Like, once or twice, by yourself.
Then never do it again.

The moment you need to work with anyone else on the application, and/or start caring about what you're pushing to production, you should stop doing this.

Right-click publish explode

But it's so easy, Damian, why are you making my life hard?

Well first, doing it properly is really not that hard. More on that in a bit.

But second, and more important, right-click publish is a fantastic way to accidentally break production. Which is bad. Obviously.

There's so much that's dependent on one person and one machine in the right-click publish scenario.

Maybe you have something installed on your machine that's not in production.
Maybe you didn't merge all the changes people made.
Maybe you did, but you resolved that tricky bit slightly wrong.
Maybe you merged successfully, but forgot to run tests.
Maybe you did run the tests, and they work fine on your machine, but not in production.
Maybe there are untested bugs that don't show up until the app is on a server.
Maybe your OS just got an upgrade and the code no longer compiles.

The list goes on.

What you really want is a repeatable, automatic pipeline that takes your code, merges it with everyone else's, runs some tests, deploys it to a test server, runs some more testing and validation, then automatically promotes it to production once you know it works.

Yeah, that sentence was long and scary, but it's honestly not hard. Donovan builds 4 of these pipelines in an hour on stage. All in different languages. From different operating systems. Even I've done it a bunch of times - you can build these things in a few minutes.

Easy.

But if you're really attached to right-clicking, you can still do that. Just install the Continuous Delivery Tools for Visual Studio and now you can right-click Configure Continuous Delivery! Much better.

But it's just a small app, there's no point building a whole pipeline!

I see you're not letting go of this. Ok:

As Donovan frequently says, "you play how you practice". If you don't bother doing things properly for small apps (that sometimes grow into big ones), then you're less likely to do it for "real" projects.

When I worked in consulting, it became standard practice to build a pipeline all the way to production on day 1 of a project (yes, that's all the time it took). Sure, at that point you're only deploying "Hello World", but it makes every subsequent change so much easier to deploy safely. And if the process needs adjusting, you're only tweaking a pipeline rather than debating whether to build one from scratch.

It's so beautiful

Let's do the math*, if it takes you 4 hours to set up a basic pipeline with Continuous Integration and Continuous Deployment you're happy with, how long until you've recovered that time?

Think about how long it takes to merge, compile, run tests, deploy to test, then deploy to production. If you're committing and deploying to (at least) test servers regularly, you'll get that time back really quickly.

Can you use right-click publish to go to production? Sure, you can, but you shouldn't.

Friends don't let friends right-click publish.

Damian Brady

I'm an Australian developer, speaker, and author specialising in DevOps, MLOps, developer process, and software architecture. I love Azure DevOps, GitHub Actions, and reducing process waste.

--