My question is about what deployable means. If it means simply 'able to be deployed', then a process with no testing is CD.
Deployable implies that all the pre-deployment process has been completed. Process will define what "deployable" means. If the process says testing is not necessary, then the software may be deployed without testing. Most processes include running some sort of test plan.
If it means 'good to deploy', then why wouldn't the business sponser be assumed to be requesting that all versions are deployed to production at the first convenient opportunity?
In the simplest case they may very well allow the dev team to deploy to production at the first convenient opportunity, but many businesses are too complex or not automated enough to do this. There are other business activities (outside of the development team) that may need to be performed prior to deployment. For example:
- A beta phase may need to be completed before deploying to production
- Sales/support may need to inform existing customers of an upcoming change
- The business may need to find a manufacturer to produce compact disks with the software on it
- The business may wish to hold off deployment for more features to be ready
If the business sponsor doesn't request deployment to production because the current version includes a change which they are not yet ready to release is that a discontinuity of delivery?
I don't think so. When we talk about continuous delivery in the software sense, delivery is to the business, not necessarily the end user. If you want to talk about continuous delivery to the end user, it may involve automating the business processes outside of the development team that would otherwise block deployment.
If so then presumably to do CD any changes to released software which are not pre-approved for release as soon as ready would need to be hidden behind feature toggles or similar until approved by the sponsor.
Feature toggles can be used to hide new features before the business is ready for them. Typically I think they would only be used if the business wants to deploy certain changes (e.g. bug fixes, minor changes) without deploying a certain new feature, and the software is at a point where it would be difficult or more effort to extract the feature from the product. I still think that in most businesses the business has the final say of what gets deployed. Even if a new feature is hidden behind a feature toggle, deployment still may have consequences that the business wants to control.
