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?
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