12

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?
  • 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. – Turtle Mar 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
4

Personally I consider the distribution of the software to a target just an intermediary step of a deployment - installation/activation of that software being necessary to complete that deployment.

To me the delivery (as in continuos 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 1st question, no, I wouldn't consider distribution and installation as reflecting the manual step differentiating continous delivery from continous 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 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.Vriens Mar 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 Cornilescu Mar 12 '17 at 21:51
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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