DevOps Stack Exchange is a question and answer site for software engineers working on automated testing, continuous delivery, service integration and monitoring, and building SDLC infrastructure. Join them; it only takes a minute:

I cannot imagine that there will be a poor "operator" at the other side of the DevOps wall, who is going to have to do something that corresponds to whatever that "manual" means ... My questions:

Is my reference (in my question) to "distribute" versus "install" close to a possible implementation of such "manual"-thing? Here is a relevant quote of my related question:

distribute to some target environment, using something like FTP (if standard copies cannot bridge the gap), but do not yet activate it in the target. That's what should be similar/close to continuous delivery, or not?

install (or activate) in some target environment, combined with things like binds, stop/start operations, etc. That's what should be similar/close to continuous deployment, or not?

For AWS deployments, I created an upload/deploy script that only the team manager has access to. So in order to deploy to production the team manager needs to run the script.
– TurtleMar 12 '17 at 13:36

Sorry to break your dreams, but we still have a ´deploy' team, which Oek is to launch DB updates on Db2-iSeries with ARCAD then chef on the Tomcart servers to deploy versions in production every 2 Thursday between 8 PM and Midnight. So, sadly, sometimes there is a poor operator (that's hopefully not their only job)
– Tensibai♦Mar 12 '17 at 20:51

Yes, in some (hopefully rare) cases that manual step is just the final human decision for deploying into production, reflecting the cultural mistrust in process automation and the mental comfort of having a human double-checking and signing off the deployment decision (thus assuming responsability for it) even if that decision is purely made based on an algorithm that can be automated (like counting pass/fail testing results).

But in general it simply reflects the fact that the decision for performing the deployment in production is not simply the result of an automated algorithm. Here would be some example such cases:

the automated decision is overwritten

deployment can be signed off even if not all quality criteria are met (we all know that this is not just a theoretical case)

the deployment is held for whatever reason, even if all criteria is met (due to market timing implications for example)

the automated algorithm is not (yet) implemented/deployed

the algorithm includes checks for some criteria depending on human decisions (say results from manual testing)

deployment is actually done in a 3rd party customer environment, following additional customer checks

So I wouldn't look at the manual step simply as an implementation issue.

Merci (oeps: thank you) for sharing your viewpoints on this. Looks like we have a different perception of "distribution". So let me just add 1 scenario: you have a window of 1 hour, for an online banking system, on an early Sunday morning, to "activate" 150.000 updated executables. And if for whatever reasons a rollback would be needed, then no negociation possible to extend that window. Would you really want to waste your time on "distribute", instead of using the time needed for that for "just in case rollback is needed? Think twice: if it takes longer then 1 hour .. you're fired ... Well???
– Pierre.VriensMar 12 '17 at 19:32

That's IMHO just an optimisation or implementation detail of the deployment itself, applicable in your case, (but that doesn't make it a rule). Just because you're executing part of your deployment before actually shutting down the old sw execution doesn't mean that the respective work is part of the delivery stage. It also doesn't necessarily mean that once you start the deployment you also need to complete it.The sw is effectively delivered (i.e. available/ready for deployment) even if you don't actually deploy.
– Dan CornilescuMar 12 '17 at 21:51

One additional consideration if you are publishing something that you are expecting other projects to consume, deploy also takes on the meaning of "publishing for others to use"

Consider a workflow where you deploy a library to a common artifact repository. This part of the process might be part of you deploying another component which requires that artifact at build time or it might simply be an update to a common library. But regardless, for that artifact, it's life cycle doesn't necessarily end by being made available for consumption by others, but the deployment of that artifact to the artifact repository may be the final stage in the developers work after they have decided to cut a new release version and before others can safely consume the new version.