<p>The terms are actually quite well defined and some authors are simply making a mess of things by using a term like 'publish' for deployment, in cases where publishing a website for example constitutes for their own process also a deployment, as there is no extra deployment step after publishing. Sometimes they use word publishing both for uploading and publishing together as all of their artifacts are public. That creates unnecessary confusion. Just to make it clear, here are the definitions:</p>

<p>Environment Definitions:</p>

<blockquote>
  <ul>
  <li><strong>build environment</strong> - Environment setup for build process.</li>
  <li><strong>runtime environment</strong> - Environment setup for execution process (test/staging/production).</li>
  </ul>
</blockquote>

<p>Artifact Lifecycle Stages:</p>

<blockquote>
  <ul>
  <li><strong>building</strong> - process of creating an artifact in build environment</li>
  <li><strong>uploading</strong> - moving artifact from build environment to repository.</li>
  <li><strong>publishing</strong> - making artifact in repository public.</li>
  <li><strong>downloading</strong> - moving artifact from repository to runtime environment</li>
  <li><strong>installing</strong> - applying artifact to runtime environment</li>
  <li><strong>deploying</strong> - using artifact in runtime environment</li>
  <li><strong>delivery</strong> - making artifact (effects) available to customer</li>
  </ul>
</blockquote>

<p>Note: <em>People often use any of those terms to mean one or more of the previous terms together.</em></p>

CC BY-SA 4.0
2018-09-13T06:34:47.153Z
seems like you refer to a product-independent source; please share a link.
Ta Mu
CC BY-SA 4.0
2018-09-13T07:09:08.560Z
These are the most commonly used terms across dozens of different platforms and products spanning over three decades of work in this field. There are slight variations, but mostly due to misunderstanding. I am as close to an authoritative source for this kind of answer as you can get, but I did not finish my book on this topic just yet. So there will be no links. Feel free to link to this answer.
Jiri Klouda
CC BY-SA 4.0
2018-09-13T07:48:56.810Z
"due to misunderstanding" is what this question targets at. Not sure whether there is irony in the reference to the book, but if not, good luck and looking forward to it!
Ta Mu
CC BY-SA 4.0
2018-09-13T09:05:35.740Z
The misunderstanding comes from the very last line of my answer. If you think about it for a while. Look at various uses of the terms through the dozens of software package management tools, artifact management tools, etc. You'll find out that in most cases where someone uses a different term for something, it is because their process skips a phase before or after. Like when publishing website actually means delivery to a customer or in SaaS where deployment often means delivery or in packaging where deploying is done simply through installing.
Jiri Klouda
CC BY-SA 4.0
2018-09-13T09:11:00.093Z
Second source of confusion is where publishing is delivery to customer, but they do their own deployment afterwards. That is where two different lifecycle processes cross each other and are mistaken for a single process. For example when you publish a jar file, which is a delivery for customer, who takes it, deploys it to their production server, delivering an internal service to their developers. Your lifecycle process mixes up with theirs confusing the order of deployment and delivery making it seem like delivery comes ahead of deployment.
Jiri Klouda
CC BY-SA 4.0
2018-09-13T06:24:50.910Z
2018-09-13T06:24:50.910Z
Jiri Klouda
<p>First things first: let us make clear what we are talking about. We are dwelling on the action of <strong>storing an artifact in an artifact repository</strong>.</p>

<p>I personnaly would rather avoid using <em>deploy</em>, because:</p>

<ul>
<li><strong>publish</strong> implies that you make an artifact available for others to consume. The term seems to do the job. It weakens a bit when you push the artifact to a <em>private</em> repository. You would then do a <em>private publication</em>. It's a lesser evil. It still makes sens.</li>
<li><strong>deploy</strong> is definitely not appropriate. Pushing a single artifact in a single repository is in no way a <em>deployement</em>. Deploy implies some sort of spreading, distributing an artifact on several environments or machines. What we are dealing with, here, is a pre-requisite to deploying; not deploying itself.</li>
</ul>

<p><strong>[Success?] Story</strong></p>

<p>For what it's worth, last time I was faced with naming the job that pushes the artifacts to the artifact repository, I was working in a Kanban context. The team came to an agreement to call the job</p>

<pre><code>version
</code></pre>

<p>because every package that was built following a merge request was a potential release candidate, therefore it was <em>versioned</em> then pushed.</p>

<p><strong>After Thoughts</strong></p>

<p>As of today, I would use the term <strong>publish</strong> (possibly privately) laking of a better term.</p>

<p>Still I don't find this satisfactory. Please feel free to leave your thoughts in the comments below!</p>

CC BY-SA 4.0
2018-09-13T11:07:27.697Z
hi, @avil.elkharrat, thanks for sharing! this question focuses on ambuguity of established terms. We do not have much from saying "no deploy is here not a term in this context" because in the Maven world (which is big and very established) it is! So every community considers they have "better" semantics.
Ta Mu
CC BY-SA 4.0
2018-09-14T08:04:18.233Z
Dear Peter, I'm not sure I got your comment. Could you please clarify? I'll be glad to rectify my answer to respond to your question in a more appropriate maner.
avi.elkharrat
CC BY-SA 4.0
2018-09-18T09:17:55.070Z
Maven is notorious for being wrong in just about everything. But the main issue is that Java and Maven in particular is only a very small fraction of the overall Development Lifecycle world. Just because Maven is big in Java does not mean its really that big. Also if an artifact is in local repository on a machine where service runs, it is considered deployed. There is the automation of which I talk in my own answer.
Jiri Klouda
CC BY-SA 4.0
2018-09-18T09:18:53.950Z
Look at this link, where they indeed use terms for downloading, uploading and publishing to repositories directly on Maven site. It's just that this also constitutes a deployment in Maven world and so they simply gloss over the difference as it is automated away. https://maven.apache.org/guides/introduction/introduction-to-repositories.html
Jiri Klouda
CC BY-SA 4.0
2018-09-18T09:22:42.360Z
And as I mentioned in the comment already. If there are two different entities, where one publishes to remote repository and another entity (or automation) rsyncs remote to local and installs and restarts services, then for the first entity, the act of publishing the artifact to the remote repository constitutes a deployment.
Jiri Klouda
CC BY-SA 4.0
2018-09-13T10:00:47.717Z
2018-09-13T10:00:47.717Z
avi.elkharrat
<p>DevOps terminology sometimes originates in products as introduced by their authors. </p>

<p>As a result, there are some standard actions described by ambigous terms. In mixed teams and large heterogeneous environments we need to agree on terms to undertstand what we actually do. </p>

<ul>
<li><p><em>publish</em>: term specific to Ant/Ivy meaning putting an artefact into binary repository. Also, some people would say "publish content updates to website".</p></li>
<li><p><em>deploy</em>: while "in the Maven world" this word describes putting an artefact to binary repository afaik, more "opsy" people deploy their servers also without having Maven in place. </p></li>
</ul>

<p>How to deal with this ambiguity (ideally, please refer to "success stories")? An explorative talk on terms meaning is not always welcome in delivery oriented stressful environments; maybe there are already better terms around? </p>

<p>For terms definitions, please refer to sources.</p>

CC BY-SA 4.0
2018-09-13T09:29:18.897Z
Great question! It's a real issue! I'll be trying to give my contribution below. Hope it helps.
avi.elkharrat
<terminology><culture><term-disambiguation>
Dealing with ambiguity of the terms publish vs. deploy
Ta Mu
# Dealing with ambiguity of the terms publish vs. deploy

(Asked by: username_0 on 2018-09-13)

DevOps terminology sometimes originates in products as introduced by their authors.

As a result, there are some standard actions described by ambigous terms. In mixed teams and large heterogeneous environments we need to agree on terms to undertstand what we actually do.

* *publish*: term specific to Ant/Ivy meaning putting an artefact into binary repository. Also, some people would say "publish content updates to website".
* *deploy*: while "in the Maven world" this word describes putting an artefact to binary repository afaik, more "opsy" people deploy their servers also without having Maven in place.

How to deal with this ambiguity (ideally, please refer to "success stories")? An explorative talk on terms meaning is not always welcome in delivery oriented stressful environments; maybe there are already better terms around?

For terms definitions, please refer to sources.

**Tags:** terminology, culture, term-disambiguation

> **Comments:**
> **username_1**: Great question! It's a real issue! I'll be trying to give my contribution below. Hope it helps.  

---

## 2 answers

### Answer by username_2 on 2018-09-13. Score: 10

The terms are actually quite well defined and some authors are simply making a mess of things by using a term like 'publish' for deployment, in cases where publishing a website for example constitutes for their own process also a deployment, as there is no extra deployment step after publishing. Sometimes they use word publishing both for uploading and publishing together as all of their artifacts are public. That creates unnecessary confusion. Just to make it clear, here are the definitions:

Environment Definitions:

> * **build environment** - Environment setup for build process.
> * **runtime environment** - Environment setup for execution process (test/staging/production).

Artifact Lifecycle Stages:

> * **building** - process of creating an artifact in build environment
> * **uploading** - moving artifact from build environment to repository.
> * **publishing** - making artifact in repository public.
> * **downloading** - moving artifact from repository to runtime environment
> * **installing** - applying artifact to runtime environment
> * **deploying** - using artifact in runtime environment
> * **delivery** - making artifact (effects) available to customer

Note: *People often use any of those terms to mean one or more of the previous terms together.*

> **Comments:**
> **username_0**: seems like you refer to a product-independent source; please share a link.  
> **username_2**: These are the most commonly used terms across dozens of different platforms and products spanning over three decades of work in this field. There are slight variations, but mostly due to misunderstanding. I am as close to an authoritative source for this kind of answer as you can get, but I did not finish my book on this topic just yet. So there will be no links. Feel free to link to this answer.  
> **username_0**: "due to misunderstanding" is what this question targets at. Not sure whether there is irony in the reference to the book, but if not, good luck and looking forward to it!  
> **username_2**: The misunderstanding comes from the very last line of my answer. If you think about it for a while. Look at various uses of the terms through the dozens of software package management tools, artifact management tools, etc. You'll find out that in most cases where someone uses a different term for something, it is because their process skips a phase before or after. Like when publishing website actually means delivery to a customer or in SaaS where deployment often means delivery or in packaging where deploying is done simply through installing.  
> **username_2**: Second source of confusion is where publishing is delivery to customer, but they do their own deployment afterwards. That is where two different lifecycle processes cross each other and are mistaken for a single process. For example when you publish a jar file, which is a delivery for customer, who takes it, deploys it to their production server, delivering an internal service to their developers. Your lifecycle process mixes up with theirs confusing the order of deployment and delivery making it seem like delivery comes ahead of deployment.  

---

### Answer by username_1 on 2018-09-13. Score: 1

First things first: let us make clear what we are talking about. We are dwelling on the action of storing an artifact in an artifact repository.
I personnaly would rather avoid using deploy, because:

publish implies that you make an artifact available for others to consume. The term seems to do the job. It weakens a bit when you push the artifact to a private repository. You would then do a private publication. It's a lesser evil. It still makes sens.
deploy is definitely not appropriate. Pushing a single artifact in a single repository is in no way a deployement. Deploy implies some sort of spreading, distributing an artifact on several environments or machines. What we are dealing with, here, is a pre-requisite to deploying; not deploying itself.

[Success?] Story
For what it's worth, last time I was faced with naming the job that pushes the artifacts to the artifact repository, I was working in a Kanban context. The team came to an agreement to call the job
version

because every package that was built following a merge request was a potential release candidate, therefore it was versioned then pushed.
After Thoughts
As of today, I would use the term publish (possibly privately) laking of a better term.
Still I don't find this satisfactory. Please feel free to leave your thoughts in the comments below!

> **Comments:**
> **username_0**: hi, @avil.elkharrat, thanks for sharing! this question focuses on ambuguity of established terms. We do not have much from saying "no deploy is here not a term in this context" because in the Maven world (which is big and very established) it is! So every community considers they have "better" semantics.  
> **username_1**: Dear Peter, I'm not sure I got your comment. Could you please clarify? I'll be glad to rectify my answer to respond to your question in a more appropriate maner.  
> **username_2**: Maven is notorious for being wrong in just about everything. But the main issue is that Java and Maven in particular is only a very small fraction of the overall Development Lifecycle world. Just because Maven is big in Java does not mean its really that big. Also if an artifact is in local repository on a machine where service runs, it is considered deployed. There is the automation of which I talk in my own answer.  
> **username_2**: Look at this link, where they indeed use terms for downloading, uploading and publishing to repositories directly on Maven site. It's just that this also constitutes a deployment in Maven world and so they simply gloss over the difference as it is automated away. https://maven.apache.org/guides/introduction/introduction-to-repositories.html  
> **username_2**: And as I mentioned in the comment already. If there are two different entities, where one publishes to remote repository and another entity (or automation) rsyncs remote to local and installs and restarts services, then for the first entity, the act of publishing the artifact to the remote repository constitutes a deployment.  

---

