Answers: <p>The answer is: it depends.</p>
  
  <p>Before I answer, I need to provide definitions for a couple of terms to prevent ambiguity.</p>
  
  <p>1) <em>Deploy</em> is defined as the <em>act of changing executables in an environment</em>. This might mean that new source is copied over, and some process is restarted. Or a new version of a docker container is placed into an orchestrator - doesn't really matter.</p>
  
  <p>2) <em>Release</em> is defined as the <em>act of making new functionality available to users of the system</em>.</p>
  
  <p>Do note that while in most organizations <em>release</em> and <em>deploy</em> happen together, they definitely don't have to be.</p>
  
  <blockquote>
    <p>Every released change (usually) requires new code to be deployed. But not every deployment of code means new changes were <em>released</em> to be used.</p>
  </blockquote>
  
  <p>Let us first look at the best case possible. Where you don't have any <em>button</em> that requires pushing, to get a deployment to happen. Every change sent to your version control system - automatically gets tested for correctness and is automatically deployed to your system.</p>
  
  <p>Now your question is optionally several different questions:</p>
  
  <ul>
  <li>Do I have a way to <em>release</em> a new feature and is that way manual? (button)</li>
  <li>Do I <em>release</em> ALL available (multiple) features at the same time when that button is pushed?</li>
  <li>Do my feature <em>releases</em> require changes to happen in multiple decoupled parts of the system?</li>
  </ul>
  
  <p>Since releasing new functionality requires some business approval. For example, the UX and correctness of the new functionality must actually bring value to your customers. It makes sense to have a "dark" release that only some friendly customers can see and provide feedback for. Then when these customers are happy with the value they get, your business can decide to make this new functionality generally available (GA).</p>
  
  <p>Should this feature break the system when released, it is possible to turn off the switch that made it released in the first place. All of which does not require any new code (or old code) to be deployed to the system, because the code is already there.</p>
  
  <p>When you consider that <em>deploy</em> and <em>release</em> are separate, it makes the decision to deploy everything together or separately simpler.</p>
  
  <hr>
  
  <p>The manufacturing world and Toyota Production System specifically have taught us that having small batches is much more beneficial than batching work items together. TPS even goes as far as to strive for single-piece-flow, where each work item is delivered to the next work center alone and not in a batch.</p>
  
  <p>Agile methodologies have taken a cue from TPS and also describe the benefits of having small-batches. These would be described as a "sprint" with a definite deployed deliverable at the end and striving to keep the sprints as short as possible. This allows to run short experiments and receive feedback regarding the value of the changes created as soon as it is possible to do something about them.</p>
  
  <p>Continuous Delivery is taking this even further by saying that any finished code, should be deployed to your systems as soon as it was auto-tested. And a release can happen at any time when someone decided to do so. And experiments can be validated as part of the development cycle. Moving the definition of "done" for a developer away from "I finished writing my code" and towards "I received feedback from customers that they received value". The shorter the feedback cycle is - minutes, seconds, etc... the better. And batching is a deterrent to short feedback.</p>
  
  <p>By having a button that by definition batches things together, would mean that risk of problems is higher. Learning from TPS, Agile and CD means that single-piece is far superior and has many benefits.</p>
  
  <hr>
  
  <p>The answer "it depends" is correct because all of what I wrote above highly depends on the maturity of your organisation. The amount of automation you have. The amount of communication you have. And many other factors.</p>
  
  <p>Separating release from deployment requires continuous integration and deployment. As well as a system that enable to select which features to release. For example <a href="https://github.com/intuit/wasabi" rel="nofollow noreferrer">https://github.com/intuit/wasabi</a> or <a href="https://www.infoq.com/presentations/etsy-deploy" rel="nofollow noreferrer">https://www.infoq.com/presentations/etsy-deploy</a></p>
  
Answers: CC BY-SA 3.0
Answers: 2017-06-24T17:29:37.817Z
Answers: It depends, indeed. That includes the superiority of the single-piece deployment. For some critical systems it may be better to deploy multiple/all pieces in a monolithic manner, to significantly reduce the number of combinations that need to be tested and validated prior to deployment.
Answers: Dan Cornilescu
Answers: CC BY-SA 3.0
Answers: 2017-06-24T04:04:44.900Z
Answers: 2017-06-24T04:04:44.900Z
Answers: Evgeny Zislis
Answers: <p>All these artifacts should be deployed at once. Otherwise, it is not truly "one click."</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-06-23T21:42:38.690Z
Answers: these are like micro services.  So all micro serves that talk to one another need to be deployed at once?  That doesn't seem right.
Answers: xtreampb
Answers: CC BY-SA 3.0
Answers: 2017-06-23T22:39:10.637Z
Answers: As opposed to deploying a microservice that can't do anything because it can't talk to another needed microservice that has yet to be deployed?
Answers: James Shewey
Answers: CC BY-SA 3.0
Answers: 2017-06-24T03:39:42.587Z
Answers: It is actually the better practice to have microservices handle failure to talk to another missing one gracefully. Having microservices decoupled from each other means exactly this. Then even when you deploy a new version for a hundred new services, the single one which fails to work correctly will not affect the other 99 because of loose coupling and graceful failure handling.
Answers: Evgeny Zislis
Answers: CC BY-SA 3.0
Answers: 2017-06-23T21:38:17.403Z
Answers: 2017-06-23T21:38:17.403Z
Answers: James Shewey
Body: <p>So one of the goals of a software company is to have one click deploy.  I think this is a major responsibility of the dev ops team.  Whether or not it is should be reserved for another conversation.  My question is that our company has multiple individual artifacts that make up a release.  Should the developers be able to one click deploy all these artifacts at once, or should each artifact be deployed individually?</p>
  
Tags: <deployment><build-pipeline>
Title: Scope for one click deploy
UserDisplayName: xtreampb
ThreadText: # Scope for one click deploy
  
  (Asked by: username_0 on 2017-06-23)
  
  So one of the goals of a software company is to have one click deploy. I think this is a major responsibility of the dev ops team. Whether or not it is should be reserved for another conversation. My question is that our company has multiple individual artifacts that make up a release. Should the developers be able to one click deploy all these artifacts at once, or should each artifact be deployed individually?
  
  **Tags:** deployment, build-pipeline
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2017-06-24. Score: 2
  
  The answer is: it depends.
  
  Before I answer, I need to provide definitions for a couple of terms to prevent ambiguity.
  
  1) *Deploy* is defined as the *act of changing executables in an environment*. This might mean that new source is copied over, and some process is restarted. Or a new version of a docker container is placed into an orchestrator - doesn't really matter.
  
  2) *Release* is defined as the *act of making new functionality available to users of the system*.
  
  Do note that while in most organizations *release* and *deploy* happen together, they definitely don't have to be.
  
  > Every released change (usually) requires new code to be deployed. But not every deployment of code means new changes were *released* to be used.
  
  Let us first look at the best case possible. Where you don't have any *button* that requires pushing, to get a deployment to happen. Every change sent to your version control system - automatically gets tested for correctness and is automatically deployed to your system.
  
  Now your question is optionally several different questions:
  
  * Do I have a way to *release* a new feature and is that way manual? (button)
  * Do I *release* ALL available (multiple) features at the same time when that button is pushed?
  * Do my feature *releases* require changes to happen in multiple decoupled parts of the system?
  
  Since releasing new functionality requires some business approval. For example, the UX and correctness of the new functionality must actually bring value to your customers. It makes sense to have a "dark" release that only some friendly customers can see and provide feedback for. Then when these customers are happy with the value they get, your business can decide to make this new functionality generally available (GA).
  
  Should this feature break the system when released, it is possible to turn off the switch that made it released in the first place. All of which does not require any new code (or old code) to be deployed to the system, because the code is already there.
  
  When you consider that *deploy* and *release* are separate, it makes the decision to deploy everything together or separately simpler.
  
  ---
  
  The manufacturing world and Toyota Production System specifically have taught us that having small batches is much more beneficial than batching work items together. TPS even goes as far as to strive for single-piece-flow, where each work item is delivered to the next work center alone and not in a batch.
  
  Agile methodologies have taken a cue from TPS and also describe the benefits of having small-batches. These would be described as a "sprint" with a definite deployed deliverable at the end and striving to keep the sprints as short as possible. This allows to run short experiments and receive feedback regarding the value of the changes created as soon as it is possible to do something about them.
  
  Continuous Delivery is taking this even further by saying that any finished code, should be deployed to your systems as soon as it was auto-tested. And a release can happen at any time when someone decided to do so. And experiments can be validated as part of the development cycle. Moving the definition of "done" for a developer away from "I finished writing my code" and towards "I received feedback from customers that they received value". The shorter the feedback cycle is - minutes, seconds, etc... the better. And batching is a deterrent to short feedback.
  
  By having a button that by definition batches things together, would mean that risk of problems is higher. Learning from TPS, Agile and CD means that single-piece is far superior and has many benefits.
  
  ---
  
  The answer "it depends" is correct because all of what I wrote above highly depends on the maturity of your organisation. The amount of automation you have. The amount of communication you have. And many other factors.
  
  Separating release from deployment requires continuous integration and deployment. As well as a system that enable to select which features to release. For example <https://github.com/intuit/wasabi> or <https://www.infoq.com/presentations/etsy-deploy>
  
  > **Comments:**
  > **username_2**: It depends, indeed. That includes the superiority of the single-piece deployment. For some critical systems it may be better to deploy multiple/all pieces in a monolithic manner, to significantly reduce the number of combinations that need to be tested and validated prior to deployment.  
  
  ---
  
  ### Answer by username_3 on 2017-06-23. Score: 0
  
  All these artifacts should be deployed at once. Otherwise, it is not truly "one click."
  
  > **Comments:**
  > **username_0**: these are like micro services.  So all micro serves that talk to one another need to be deployed at once?  That doesn't seem right.  
  > **username_3**: As opposed to deploying a microservice that can't do anything because it can't talk to another needed microservice that has yet to be deployed?  
  > **username_1**: It is actually the better practice to have microservices handle failure to talk to another missing one gracefully. Having microservices decoupled from each other means exactly this. Then even when you deploy a new version for a hundred new services, the single one which fails to work correctly will not affect the other 99 because of loose coupling and graceful failure handling.  
  
  ---
  
  