1

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?

Improve this question

2 Answers 2

Reset to default
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

Improve this answer
1
  • 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.
    – Dan Cornilescu
    Jun 24, 2017 at 17:29
0

All these artifacts should be deployed at once. Otherwise, it is not truly "one click."

Improve this answer
3
  • 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.
    – xtreampb
    Jun 23, 2017 at 21:42
  • 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?
    – James Shewey
    Jun 23, 2017 at 22:39
  • 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.
    – Evgeny Zislis
    Jun 24, 2017 at 3:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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