Thread by @yacinehmito

This prompted be to search _exactly_ what was the difference. I was not ready for the linguistic mess... Let's go on a journey to figure out what people think which is which. 🎬

https://twitter.com/mipsytipsy/status/1340521707149303808

Here's the beginning of the first page of results on Google (that I get; you make have something different).

TL;DR: Every result has its own definitions. The thing is a mess and we need an authoritative source to straighten that out.

The first result, which is highlighted, comes from english.stackechange.com. Odd, but the question is well asked. (Funnily enough, the answer highlighted by Google in neither the accepted one nor the top-rated one...)
english.stackexchange.com/questions/1827….

Here's basically what Google's highlighted answer says:
- Release = a specific revision that is a given a name / version
- Deploy = put a release in production

The top-rated and accepted answer is consistent with this, although is also adds that "due to people drawing from varied experiences and definitions, there will often be confusion". As we'll see later, that's an understatement.

Second result is from bmc's blog. From what I gather, @BMCSoftware is a company selling a bunch of software products to Enterprise, some in the domains of observability, DevOps, orchestration, etc...

The article is great. Props to bmc, and its author @JosephNduhiu, for avoiding the trappings of marketing mumbo-jumbo.
bmc.com/blogs/software…

It reads: "The key distinction between these deployment and release is the business rationale."

Continuing: "Deployment doesn’t necessarily mean users have access to features, (...). Some companies will release at the same time as deployment to production is taking place."

"Others will choose to wait, thereby having the new features in production but not availed to users until the business decides." End of quote.

That's not exactly consistent with the definitions from StackExchange. Although bmc's article also mentions giving names to revision, it underscores that it belongs to the business' scope.

Basically, we end up with the following distinction:
- Deploy = pushing code to a remote machine (potentially in production)
- Release = making a change available to users

Trouble starts brewing...

Next up is a very succinct article from @BeyondAgilityCH, which seems to be a one-man Agile consulting company. The definitions are short and to the point, and are consistent with bmc's article.
beyond-agility.com/deployment-vs-…

It basically says:
- Deploy = Put the functionality in production
- Release = Put the functionality in the hands of end-users

Problem: right after, it defines CI/CDs, and that raises other questions.

In defines Continuous Deployment as a deployment practice, and Continuous Delivery as a release practice. Is it really the case? That's at least not how Martin Fowler defines it. Continuous Delivery just means "can deploy anytime". martinfowler.com/bliki/Continuo…

So, by trying to makes sense of a linguistic mess on one set of terms, I end up being confused on another... If we assume that Beyond Agility's article is consistent with Martin Fowler's definitions, then it is not consistent with itself regarding Release vs. Deploy.

Next up is a Medium article by @TurbineLabs. Visiting their website, I don't understand what they do, except that it is related to data and AI. (I don't known how some businesses can be both successful and opaque, but I guess I am just not the target.)
blog.turbinelabs.io/deploy-not-equ…

It starts well, with "As an industry, we haven’t done a great job of standardizing our use of these terms, even though we’ve radically improved operations practices and tooling over the past decade." 👏
The author, @artgillespie, then provides their own internal definitions.

Here's a sum up of deploy vs. release from Turbine Labs' article:
- Deploy = Put the new code in the production infrastructure
- Release = Route traffic to the newly deployed service

That looks consistent with bmc's and Beyond Agility's definitions. But is it?

It seems to narrow down the distinction to a technical concern, by specifically mandating that the way to deliver the new functionality to the end user is by the routing of traffic to a new instance. It's odd, but understandable in the context of the article.

Indeed, the distinction between deploy (putting code out) and release (making use of the code) allows for the definition of "patterns" of releases. Having two different words for those technical activities makes it easier to talk about Canary, Blue-green and In-place.

That is however quite limiting. By using these words to define something so narrow, we prevent their use in a broader context. What happens if I want to release via a feature flag? I can't, because releasing implies routing at the network level.

Next article is from @Atlassian, written @stenpittet. It is about defining CI/CDs. It provides no actual definitions for what a deploy or a release is. It's OK, as it is not the point of the article, but that's what I asked Google though. 😅
atlassian.com/continuous-del…

In the article, you can infer the meaning of each term by their uses:
- Deploy = Putting code in a remote machine
- Release = Deploy, but specifically in production

So, not consistent with either of the previous definitions.
(CI/CDs are consistent with Martin Fowler's though)

Unfortunately the article is not dated. I bet it's not very recent, because towards the end, it mentions that the whole organisation needs to adapt for the high-cadence releases imposed by Continuous Deployment. That's not necessary: Feature Flagging is now a common solution.

I'm not doing the rest of the Google results, because that's enough to make my point, which is: as an industry, we need to get our language straight.