Answers: <p>Personally, I consider the <em>distribution</em> 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.</p>
  <p>To me the <em>delivery</em> (as in <em>continuous delivery</em>) stops when the software to be deployed is created and made <em>available</em> for deployment (i.e. for distribution, installation and activation).</p>
  <p>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.</p>
  <p>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).</p>
  <p>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:</p>
  <ul>
  <li>the automated decision is overwritten
  <ul>
  <li>deployment can be signed off even if not all quality criteria are met (we all know that this is not just a theoretical case)</li>
  <li>the deployment is held for whatever reason, even if all criteria is met (due to market timing implications for example)</li>
  </ul>
  </li>
  <li>the automated algorithm is not (yet) implemented/deployed</li>
  <li>the algorithm includes checks for some criteria depending on human decisions (say results from manual testing)</li>
  <li>deployment is actually done in a 3rd party customer environment, following additional customer checks</li>
  </ul>
  <p>So, I wouldn't look at the manual step simply as an implementation issue.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-12T19:32:24.290Z
Answers: 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???
Answers: Pierre.Vriens
Answers: CC BY-SA 3.0
Answers: 2017-03-12T21:51:14.893Z
Answers: 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.
Answers: Dan Cornilescu
Answers: CC BY-SA 4.0
Answers: 2017-03-12T15:41:00.340Z
Answers: 2023-03-15T18:20:05.847Z
Answers: 2023-03-15T18:20:05.847Z
Answers: Dan Cornilescu
Answers: <p>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"</p>
  
  <p>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.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-12T21:02:40.237Z
Answers: 2017-03-12T21:02:40.237Z
Answers: hvindin
Body: <p>The accepted answer to my question about "<a href="https://devops.stackexchange.com/questions/488">How does continuous integration relate to continuous delivery / deployment?</a>" also explains the <strong><em>small difference</em></strong> between <em>continuous delivery</em> and <em>continuous deployment</em>. 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:</p>
  
  <ul>
  <li>Auto(matic).</li>
  <li>Manual.</li>
  </ul>
  
  <p>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:</p>
  
  <ul>
  <li>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:</li>
  </ul>
  
  <blockquote>
    <ul>
    <li><strong><em>distribute</em></strong> 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 <em>continuous delivery</em>, or not?</li>
    <li><strong><em>install</em></strong> (or <em>activate</em>) in some target environment, combined with things like binds, stop/start operations, etc. That's what should be similar/close to <em>continuous deployment</em>, or not?</li>
    </ul>
  </blockquote>
  
  <ul>
  <li>What are other possible implementations of it?</li>
  </ul>
  
Comments: CC BY-SA 3.0
Comments: 2017-03-12T13:36:04.937Z
Comments: 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.
Comments: Turtle
Comments: CC BY-SA 3.0
Comments: 2017-03-12T20:51:33.280Z
Comments: 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)
Comments: Tensibai
Tags: <continuous-deployment>
Title: How to implement the manual step at the end of continuous delivery?
UserDisplayName: Pierre.Vriens
ThreadText: # How to implement the manual step at the end of continuous delivery?
  
  (Asked by: username_0 on 2017-03-12)
  
  The accepted answer to my question about "[How does continuous integration relate to continuous delivery / deployment?](https://devops.stackexchange.com/questions/488)" 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?
  
  **Tags:** continuous-deployment
  
  > **Comments:**
  > **username_1**: 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.  
  > **username_2**: 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)  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2017-03-12. Score: 5
  
  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.
  
  > **Comments:**
  > **username_0**: 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???  
  > **username_3**: 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.  
  
  ---
  
  ### Answer by username_4 on 2017-03-12. Score: 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.
  
  
  ---
  
  