11

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.

Improve this question
1
  • Great question! It's a real issue! I'll be trying to give my contribution below. Hope it helps.
    – avi.elkharrat
    Commented Sep 13, 2018 at 9:29

2 Answers 2

Reset to default
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.

Improve this answer
5
  • seems like you refer to a product-independent source; please share a link.
    – Ta Mu
    Commented Sep 13, 2018 at 6:34
  • 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
    Commented Sep 13, 2018 at 7:09
  • "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
    Commented Sep 13, 2018 at 7:48
  • 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
    Commented Sep 13, 2018 at 9:05
  • 1
    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
    Commented Sep 13, 2018 at 9:11
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!

Improve this answer
5
  • 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
    Commented Sep 13, 2018 at 11:07
  • 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
    Commented Sep 14, 2018 at 8:04
  • 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
    Commented Sep 18, 2018 at 9:17
  • 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. maven.apache.org/guides/introduction/…
    – Jiri Klouda
    Commented Sep 18, 2018 at 9:18
  • 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
    Commented Sep 18, 2018 at 9:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.