9 ms·

The Difference Between CI and CD

194 points by jpdel 7y ago

coderinsg 7y ago
Well written. The line between CI and CD has been blurred esp when they’re commonly mentioned together. Many cant tell the difference
- hinkley 7y ago
  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.
  - tomxor 7y ago
    > 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.
    - greglindahl 7y ago
      It took me a few minutes to set up CI for each of my smallish open source modules - and it caught problems with older Python versions quickly. How am I doing it wrong?
    - jdlshore 7y ago
      Small-scale CI is trivial to set up. A build script and integration VM is all you need. If it's difficult, there's most likely hygiene factors in your codebase that are worth resolving. https://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html https://www.jamesshore.com/Blog/Continuous-Integration-on-a-...
hinkley 7y ago
> 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.
- jdlshore 7y ago
  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.
  - richardlblair 7y ago
    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.
  - Ididntdothis 7y ago
    "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.
devonkim 7y ago
In SRE and DevOps land we’ve mostly had arguments over continuous deployment vs continuous delivery and have mostly let feature engineers decide how they want to use the possible approaches and options available
cottonseed 7y ago
> Keep it short. 3-7 minutes should be max. Who has a 3-7m CI build here?
- smcleod 7y ago
  I would say for me that's a pretty reasonable estimate for microservice architecture applications / services, of course large legacy monoliths take longer but not more than say 15-20 minutes at most.
  - cottonseed 7y ago
    3m seems aggressive to do builds and spin up infrastructure for anything non-trivial. Reading a bit closer, I see the author describes CI as a sanity check, "ensur[ing] the bare minimum" and doesn't consider deploying on every commit. Maybe 3-7m is more realistic then. However, I'm slightly surprised by this definition of CI. According to Fowler [0], "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time. ... The key test is that a business sponsor could request that the current development version of the software can be deployed into production at a moment's notice." So having CI gates on the development version that are weaker than the release tests would not seem to be continuous delivery according to his definition. We're currently releasing on every commit and our CI build (which implements continuous delivery) takes about 15m. [0] https://martinfowler.com/bliki/ContinuousDelivery.html https://martinfowler.com/bliki/ContinuousDelivery.html
    - colinchartier 7y ago
      Hey, I've been working on a CI tool that skips the "non-trivial" bits for arbitrary Linux workflows, would love your feedback: https://layerci.com https://layerci.com
      - jpdel 7y ago
        Is this doing anything else than leveraging Docker multi layers caching?
s_Hogg 7y ago
The title reminds me a lot of all those fatuous articles about the difference between statistics and machine learning. This one is alright though - I wonder how we got to lumping CI and CD together as is commonplace now.
- jpdel 7y ago
  I think this is a business trend unfortunately. Tools tackling the CI space wanted a piece of CD and then boom. Things became the same :)
danpalmer 7y ago
I wish more CI/CD services understood this. We recently moved from Jenkins to CircleCI, and while the PR experience has improved dramatically (no queueing, faster builds), the _release_ process is far worse. The reason seems to be that CircleCI just treats CD as CI. In reality doing CD requires high correctness, care, and nuance. For example... with CircleCI there's no way to ensure that you release your code in the correct order other than to manually wait to merge your code until the previous code has gone out. That's not _continuous_. This is a very basic requirement. So perhaps they are not a CD service as they pitch themselves as? That means deploys are manually triggered then? Nope, there is no way to manually trigger a build. I wish this was an isolated example, but I've yet to see a CI/CD service that is easy to build fast, correct, deployments with. Jenkins is correct but not fast or easy, Circle is fast but not correct, and most others I've used are none of these at all.
a_imho 7y ago
The process of Continuous Integration is independent of any tool. This is one of my pet peeves, people using the term CI referring to the tooling. For me this alone invalidates anything they have to say about the subject.
bump64 7y ago
I am using Azure Devops for the past couple of years and they have kind of nailed it. You have builds that do most of the CI and Releases which can be fine tuned to do complex deployments and complete the CD story. Then you can set them as a requirement for the pull request approval to the main and branch it helps to guarantee healthy trunk. I don't agree that CI is a team problem and CD is an engineering problem. If you are following infrastructure as code principles it is everyone's problem because if you don't add how your new feature should be deployed it will break the CI and CD pipelines and you won't be able to merge it.
- jpdel 7y ago
  Also using Azure DevOps and it is indeed very well structured. As for CI/CD differences: how many commits can actually affect code and infrastructure? I think this is part of the engineering problem at the end of the day.
agustif 7y ago
I've been using [branchci](https://branchci.com https://branchci.com) (free tier) recently to build, lint, and deploy a wp site and been very happy with it!

194 points by jpdel 7y ago

Well written. The line between CI and CD has been blurred esp when they’re commonly mentioned together. Many cant tell the difference

hinkley 7y ago
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.
- tomxor 7y ago
  > 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.
  - greglindahl 7y ago
    It took me a few minutes to set up CI for each of my smallish open source modules - and it caught problems with older Python versions quickly. How am I doing it wrong?
  - jdlshore 7y ago
    Small-scale CI is trivial to set up. A build script and integration VM is all you need. If it's difficult, there's most likely hygiene factors in your codebase that are worth resolving. https://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html https://www.jamesshore.com/Blog/Continuous-Integration-on-a-...

hinkley 7y ago

> 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.

jdlshore 7y ago
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.
- richardlblair 7y ago
  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.
- Ididntdothis 7y ago
  "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.

devonkim 7y ago

In SRE and DevOps land we’ve mostly had arguments over continuous deployment vs continuous delivery and have mostly let feature engineers decide how they want to use the possible approaches and options available

cottonseed 7y ago

> Keep it short. 3-7 minutes should be max. Who has a 3-7m CI build here?

smcleod 7y ago
I would say for me that's a pretty reasonable estimate for microservice architecture applications / services, of course large legacy monoliths take longer but not more than say 15-20 minutes at most.
- cottonseed 7y ago
  3m seems aggressive to do builds and spin up infrastructure for anything non-trivial. Reading a bit closer, I see the author describes CI as a sanity check, "ensur[ing] the bare minimum" and doesn't consider deploying on every commit. Maybe 3-7m is more realistic then. However, I'm slightly surprised by this definition of CI. According to Fowler [0], "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time. ... The key test is that a business sponsor could request that the current development version of the software can be deployed into production at a moment's notice." So having CI gates on the development version that are weaker than the release tests would not seem to be continuous delivery according to his definition. We're currently releasing on every commit and our CI build (which implements continuous delivery) takes about 15m. [0] https://martinfowler.com/bliki/ContinuousDelivery.html https://martinfowler.com/bliki/ContinuousDelivery.html
  - colinchartier 7y ago
    Hey, I've been working on a CI tool that skips the "non-trivial" bits for arbitrary Linux workflows, would love your feedback: https://layerci.com https://layerci.com
    - jpdel 7y ago
      Is this doing anything else than leveraging Docker multi layers caching?

s_Hogg 7y ago

The title reminds me a lot of all those fatuous articles about the difference between statistics and machine learning. This one is alright though - I wonder how we got to lumping CI and CD together as is commonplace now.

jpdel 7y ago
I think this is a business trend unfortunately. Tools tackling the CI space wanted a piece of CD and then boom. Things became the same :)

danpalmer 7y ago

I wish more CI/CD services understood this. We recently moved from Jenkins to CircleCI, and while the PR experience has improved dramatically (no queueing, faster builds), the _release_ process is far worse. The reason seems to be that CircleCI just treats CD as CI. In reality doing CD requires high correctness, care, and nuance. For example... with CircleCI there's no way to ensure that you release your code in the correct order other than to manually wait to merge your code until the previous code has gone out. That's not _continuous_. This is a very basic requirement. So perhaps they are not a CD service as they pitch themselves as? That means deploys are manually triggered then? Nope, there is no way to manually trigger a build. I wish this was an isolated example, but I've yet to see a CI/CD service that is easy to build fast, correct, deployments with. Jenkins is correct but not fast or easy, Circle is fast but not correct, and most others I've used are none of these at all.

a_imho 7y ago

The process of Continuous Integration is independent of any tool. This is one of my pet peeves, people using the term CI referring to the tooling. For me this alone invalidates anything they have to say about the subject.

bump64 7y ago

I am using Azure Devops for the past couple of years and they have kind of nailed it. You have builds that do most of the CI and Releases which can be fine tuned to do complex deployments and complete the CD story. Then you can set them as a requirement for the pull request approval to the main and branch it helps to guarantee healthy trunk. I don't agree that CI is a team problem and CD is an engineering problem. If you are following infrastructure as code principles it is everyone's problem because if you don't add how your new feature should be deployed it will break the CI and CD pipelines and you won't be able to merge it.

jpdel 7y ago
Also using Azure DevOps and it is indeed very well structured. As for CI/CD differences: how many commits can actually affect code and infrastructure? I think this is part of the engineering problem at the end of the day.

agustif 7y ago

I've been using [branchci](https://branchci.com https://branchci.com) (free tier) recently to build, lint, and deploy a wp site and been very happy with it!