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 possible
Have automated tests you can trust

---

In traditional build process, without using continuous delivery approach, We commit the code in master branch, for multiple reasons, mainly for collaboration among developers and testers.

With respect to first principle, How can every commit be a potential release?

Vellavelleity

It says every build is a potential release, not every commit. And with automated tests you can trust successful build is a build ready for production. – Vitrine

Answer 1

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.

Haven

If Joe and John are co-implementing a new feature and Joe has something to commit in master branch. Because, code reviewers can create their own branches(from master branch) for code review... I mean PullRequest process. Does that mean Joe's commit is ready for a release? – Vellavelleity

Do you think using SonarQube in the piepline for CodeReview(static code analysis) can help in such scenario? Manual code reviews cannot stop the pipeline to run... once Joe commits the code. Then the point "Every commit is a potential release" make sense to me – Vellavelleity

Another point to add... to make every commit a potential release, the work divided between Joe and John should not be mutually dependent at any stage of pipeline. – Vellavelleity

About first question: if I understand you correctly, Joe's commit doesn't make sense for new functionality without John's commits, but in this case you will not run build before all changes are made or you will have failed tests, so it will not be ready for release. On the other side, if auto tests were not failed, then probably Joe's commit didn't change previous functionality and you have the stable build - so you have the release candidate (even if the new functionality is not working, previous functionality working as well). – Haven

About second question: I think that SonarQube cannot be used as main code review instrument, only as addition to manual code review. To succeed Every commit is a potential release point you need to have auto-tests for all functionality (at least for all critical functionality). Then every non stable commit will fail the build. – Haven

Also, to use continuous delivery in the proper way, instead of committing right to master, it's recommended to use GitFlow workflow, at least use feature branches for new changes and merge to master when feature branch is stable. So, you're not allowed to commit to master directly, only to merge a stable feature branches. – Haven

Answer 2

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.

Singapore

Wrt first principle, considering the gitflow, my question is, for any production bugfix, you branch both release branch and Develop branch. Now, does these multiple bugfix commits on Develop branch will go through QA pipeline for for next potential release? – Vellavelleity

Can't really answer - I wouldn't use gitflow to start with, my mind hurts ;) I'd use TBD with release branches. I'd submit the fix to production and, if applicable, to master as well. Ideally each branch using a gating CI system to perform the QA checks and making the actual commits after they pass. This doesn't need to be complicated at all. – Singapore