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.

Ta Mu
  • 6,792
  • 5
  • 43
  • 83

2 Answers2

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.

Jiri Klouda
  • 5,867
  • 1
  • 22
  • 54
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!

avi.elkharrat
  • 346
  • 2
  • 5