3 ms·

You shouldn't do continuous integration without continuous deployment, because you don't know whether you're relying on code that is not ready to go to prod. An

You shouldn't do continuous integration without continuous deployment, because you don't know whether you're relying on code that is not ready to go to prod. And you shouldn't do continuous deployment unless your test coverage (including load+perf) is so exhaustive that every possible change has zero risk in prod. Literally every team I've ever worked on had to manage production deployment tactically in terms of "are the right people available if we roll this right now" and "how much effort would the rollback be" and "is this an especially important day for our customers". New features should be on branches off master, and master is the code we've already pushed to prod and agreed is good enough not to roll back.

Silhouette 11y ago
Some people seem to think the only software that gets developed any more is running on a web server, that its developers can and should always have direct access to production servers, that pushing minor changes to those production servers several times a day with minimal oversight or control is a badge of honour, and that having serious failures in production now and then is acceptable. No doubt for some software development projects this is all true. For many others, it is not. Processes and tools that work well for a team in one context might be completely inappropriate for a team in another.