The Difference Between CI and CD
1–10 of 60 posts
Re: The Difference Between CI and CD
#2Well written. The line between CI and CD has been blurred esp when they’re commonly mentioned together. Many cant tell the difference
Re: The Difference Between CI and CD
#3Well written. The line between CI and CD has been blurred esp when they’re commonly mentioned together. Many cant tell the difference
Few things are as aggravating to me as people who say they understand CD but then manage avoid practicing any of the tenets of CI.
Automated builds are the smallest part of CI. Necessary, but drastically insufficient. If that's all you're doing you've missed the forest for the trees.
Re: The Difference Between CI and CD
#4> The scenario we want to avoid is that a faulty commit makes it to the main branch.
Close. The scenario we want to minimize is faulty code on the main branch. As your team grows, as the number of commits go up, it becomes a game of chance. Sooner or later something will get through. The more new teammates you have, the more often that will happens.
This is an inescapable cost of growth. The cost of promoting people to management. The cost of starting new projects. Occasionally you can avoid it as a cost of turnover, but you will have turnover at some point.
What matters most is how long the code is "broken" (including false positives) before it is identified, mitigated, and fully corrected. The amount of work you can do to keep these number relatively stable in the face of change is profound.
If you insist on no errors on master ever you will kill throughput. You will create situations where the only failures are big, which is neck deep in the philosophy that CI rejects: that problems are to be avoided instead of embraced and conquered.
Re: The Difference Between CI and CD
#5> The scenario we want to avoid is that a faulty commit makes it to the main branch. Close. The scenario we want to minimize is faulty code on the main branch. As your team grows, as the number of commits go up, it becomes a game of chance. Sooner or later something will get through. The more new teammates you have, the more often that will happens. This is an inescapable cost of growth. The cost of promoting people…
It's possible (and not that hard) to define an integration process that prevents faulty commits from being integrated to the main branch.
> If you insist on no errors on master ever you will kill throughout.
Not sure why you believe this. It hasn't been my experience; just the opposite, in fact. By using CI in conjunction with a process that prevents errors on master, everything goes more smoothly, because people don't get stalled by the broken master.
Re: The Difference Between CI and CD
#6> The scenario we want to avoid is that a faulty commit makes it to the main branch. Close. The scenario we want to minimize is faulty code on the main branch. As your team grows, as the number of commits go up, it becomes a game of chance. Sooner or later something will get through. The more new teammates you have, the more often that will happens. This is an inescapable cost of growth. The cost of promoting people…
It's possible (and not that hard) to define an integration process that prevents faulty commits from being integrated to the main branch. > If you insist on no errors on master ever you will kill throughout. Not sure why you believe this. It hasn't been my experience; just the opposite, in fact. By using CI in conjunction with a process that prevents errors on master, everything goes more smoothly, because people don…
You're both right.
The healthy mentality is to realize mistakes will happen. This creates a healthier culture when things do break.
However, you should take every step to ensure it doesn't happen. You should act as though you want to prevent all faults from hitting you master branch.
Re: The Difference Between CI and CD
#7> The scenario we want to avoid is that a faulty commit makes it to the main branch. Close. The scenario we want to minimize is faulty code on the main branch. As your team grows, as the number of commits go up, it becomes a game of chance. Sooner or later something will get through. The more new teammates you have, the more often that will happens. This is an inescapable cost of growth. The cost of promoting people…
It's possible (and not that hard) to define an integration process that prevents faulty commits from being integrated to the main branch. > If you insist on no errors on master ever you will kill throughout. Not sure why you believe this. It hasn't been my experience; just the opposite, in fact. By using CI in conjunction with a process that prevents errors on master, everything goes more smoothly, because people don…
"It's possible (and not that hard) to define an integration process that prevents faulty commits from being integrated to the main branch.
"
You should strive to do that but you shouldn't be surprised that despite all effort mistakes still happen from time to time.
Re: The Difference Between CI and CD
#8Well written. The line between CI and CD has been blurred esp when they’re commonly mentioned together. Many cant tell the difference
Few things are as aggravating to me as people who say they understand CD but then manage avoid practicing any of the tenets of CI. Automated builds are the smallest part of CI. Necessary, but drastically insufficient. If that's all you're doing you've missed the forest for the trees.
> Few things are as aggravating to me as people who say they understand CD but then manage avoid practicing any of the tenets of CI.
It is completely reasonable to utilise one without the other, not all projects are giant multi author efforts trying to wrangle commits.
For instance if you have lots of small projects being worked on independently in parallel with no more than one or two authors on a repo at a time, CI is not going to be worth the investment... but CD still has it's uses.
Re: The Difference Between CI and CD
#9> The scenario we want to avoid is that a faulty commit makes it to the main branch. Close. The scenario we want to minimize is faulty code on the main branch. As your team grows, as the number of commits go up, it becomes a game of chance. Sooner or later something will get through. The more new teammates you have, the more often that will happens. This is an inescapable cost of growth. The cost of promoting people…
> If you insist on no errors on master ever you will kill throughput.
There are a large number of automated tools which will help you prevent merging code that could break master: https://github.com/chdsbd/kodiak#prior-art--alternatives. The basic approach is to make a new branch from master, apply one or more commits on top of that branch, run the tests, and if tests pass, merge those commits (with fast-forward) back onto master. This makes it very difficult to get broken commits on master, as they have to pass the tests before. It is possible if you have a flaky test suite, but in my experience it happens very rarely, and is usually very easy to fix if something creeps in. In my experience, they speed up throughput, not slow it down, especially when you account for the disruption that merging broken code to master can be.
https://graydon2.dreamwidth.org/1597.html has a good discussion of this:
The Not Rocket Science Rule Of Software Engineering:
automatically maintain a repository of code that always passes all the tests
Re: The Difference Between CI and CD
#10> The scenario we want to avoid is that a faulty commit makes it to the main branch. Close. The scenario we want to minimize is faulty code on the main branch. As your team grows, as the number of commits go up, it becomes a game of chance. Sooner or later something will get through. The more new teammates you have, the more often that will happens. This is an inescapable cost of growth. The cost of promoting people…
> If you insist on no errors on master ever you will kill throughput. There are a large number of automated tools which will help you prevent merging code that could break master: https://github.com/chdsbd/kodiak#prior-art--alternatives . The basic approach is to make a new branch from master, apply one or more commits on top of that branch, run the tests, and if tests pass, merge those commits (with fast-forward) ba…
The problem with a popular repository can be that running the tests can take longer than the time you have between merges.
In GitLab we made merge trains https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipeli... to solve this problem automatically.
With merge trains the merge requests with a passing feature branch is placed in a queue and tests are run against the combination of that branch and all the branches before it merged in. Since tests will pass 95%+ of the time the feature branches passes this can speed up the amount of merges you can get into master by 10x or more.