If you don’t do CD, it will either be more expensive because you have to maintain two processes or there is a good chance it will fail when you need it most because the critical delivery path wasn’t well exercised.
Why two? Release process is always the same, only decision to go live is manual and can be based on different criteria in different circumstances. CD is enabled by certain level of automation, which is nice to have, but if you do not aim to have CD, a good manual process can still work and may be actually less expensive in certain scenarios if you consider delivery pipeline TCO.
> decision to go live is manual and can be based on different criteria in different circumstances
..this conflicts with previously stated requirement:
> a proper support process where critical fixes can be delivered within hours or minutes.
That the decision to go live is based on criteria and circumstances implies that there are criteria and circumstances that make a release ineligible to go live at those times.
If those criteria and/or circumstances are frequently blocking, then the manual pipeline is not prepared to deliver critical fixes on short notice, because the release pipeline is often blocked (whether CD or not)
If those criteria and/or circumstances are infrequently blocking, and the manual release process is also exercised infrequently, then it increases the risk that the manual release process may not work on a critical timeline, because something may be broken but unnoticed from lack of use.
If those criteria and/or circumstances are infrequently blocking, and the manual release process is also exercised frequently without problems, then the critical release should be fine. (Although this case seems suspiciously like CD and I’d be a little surprised to hear that the cost of automating such a finely tuned pipeline is significantly greater than the cost of the manpower to run it manually).
>> a proper support process where critical fixes can be delivered within hours or minutes.
>That the decision to go live is based on criteria and circumstances implies that there are criteria and circumstances that make a release ineligible to go live at those times.
Indeed: you normally do not release the code that is not ready and you do not release the code that will alter the business process before business users are ready to accept the change. It does not mean that it is impossible to deliver a critical fix in such circumstances. Let's look at the delivery process first to understand, if there's really any contradiction.
In a well organized process you have branches and you probably use pull requests to deliver the code to the main branch. This branch does not have to be the same as the branch of the last released code, meaning that you can actually work in both branches. The release cycle on the main branch can be long if your company can manage the complexity of bigger projects. However, if there's a critical bug found, you can develop the fix on the production code branch, then release it quickly and merge the changes to main. The fact that you normally do not push changes as fast as possible to production means that you do not have continuous delivery, but it does not mean that you cannot have automated deployment or even continuous deployment (which would be in this case triggered by a merge to designated branch after automated tests on certain branches are passed).
Now, how about continuous deployment? It appears, you can actually have continuous delivery or automated deployment, but not continuous deployment. For continuous delivery it is sufficient to produce quickly build artifacts via CI, but the way they are released can be really different and may not involve deployment by merge. I worked in an organization where production system was physically separated from delivery pipeline and artifacts had to be copied to a flash drive. We could still produce a change and get it live within 10-15 minutes, because the manual process was actually well-thought and optimized to reduce human errors. We had releases almost on daily basis and we had few times when we actually delivered changes very fast (once it involved a rollback for a complicated $100M transaction through 20 systems that went through because of a missing validation requirement). You may even have a fully automated deployment triggered by one click: the only difference with continuous deployment will be that it's not done once the build is green.
To sum up, CD (continuous delivery) is not the same as CD (continuous deployment) and you can have just one of them or none, still having the automated deployment process. Or not having it, but still being able to deliver critical fixes quickly and with minimal risks. I do not know, what is the process at SpaceX, but the fact that they did fast rollout does not mean they have CD in either sense or it even makes sense for them. It's better to ask their team. :)
