Principles of continuous delivery

Question

As mentioned here,

Below are the principles for continuous delivery.

Every build is a potential release
Eliminate manual bottlenecks
Automate wherever p         


        

Answer 1

Continuous delivery is an extension of continuous integration, see How does continuous integration relate to continuous delivery / deployment?. And from the CI practices:

Every commit should build on an integration machine

So yes, in CI/CD every commit is going to be built and, if all CD criteria are met (emphasis on potential!), the commit is deliverable (or deployable if D in CD stands for deployment). If not then the issue must be addressed.

There may be exceptions, for example due to business requirements or resource limitations, in which the delivery/deployment pipeline is not triggered for every successful CI commit. But that complicates identifying and fixing regressions.

But committing changes with dependencies on other, not-yet-committed changes (as mentioned in comments) is not compatible with the CI/CD methodology. Work-in-progress commits in such context are still possible using feature toggles/flags and/or branch-by-abstraction techniques which can hide temporarily unsatisfied dependencies in order to not cause regressions.

Answer 2

It's quite simple - if you created a commit and pushed changes to master and after that you run a build and your automated tests are all executed successfully, then this build can be used as a release.

So, the principle is more related to build rather than to commit, but if you've configured to start a build for every change that pushed to master (Automate wherever possible principle), then in this case it's a synonym.