How to implement the manual step at the end of continuous delivery?

The accepted answer to my question about "How does continuous integration relate to continuous delivery / deployment?" also explains the small difference between continuous delivery and continuous deployment. It appears to be related to the answer to a question like "How do you want to deploy to production, whereas these are the (exclusive) options to pick from:

• Auto(matic).

• Manual.

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?

• What are other possible implementations of it?

Personally, I consider the distribution of the software to a target just an intermediary step of a deployment - installation/activation of that software is still needed to complete that deployment.

To me the delivery (as in continuous delivery) stops when the software to be deployed is created and made available for deployment (i.e. for distribution, installation and activation).

So, to answer your first question: No, I wouldn't consider distribution and installation as reflecting the manual step differentiating continuous delivery from continuous deployment.

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 responsibility 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.

StackExchange DevOps Q#494, answer score: 5