2

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?

hakamairi
  • 4,464
  • 4
  • 30
  • 53
overexchange
  • 15,768
  • 30
  • 152
  • 347
  • 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. – user7860670 Jan 13 '19 at 19:17

2 Answers2

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.

biruk1230
  • 3,042
  • 4
  • 16
  • 29
  • 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? – overexchange Jan 13 '19 at 21:36
  • 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 – overexchange Jan 13 '19 at 21:40
  • 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. – overexchange Jan 13 '19 at 21:45
  • 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). – biruk1230 Jan 13 '19 at 22:24
  • 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. – biruk1230 Jan 13 '19 at 22:48
  • Also, to use continuous delivery in the proper way, instead of committing right to master, it's recommended to use [GitFlow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) 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. – biruk1230 Jan 13 '19 at 22:48
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.

Dan Cornilescu
  • 39,470
  • 12
  • 57
  • 97
  • Wrt first principle, considering the [gitflow](https://i.stack.imgur.com/7mjrz.png), 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? – overexchange Jan 18 '19 at 19:20
  • Can't really answer - I wouldn't use gitflow to start with, my mind hurts ;) I'd use [TBD](https://trunkbaseddevelopment.com/) 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. – Dan Cornilescu Jan 18 '19 at 19:44