Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Difference Between CI and CD

fire.ci

Post reply on HN
Print view View original

11–20 of 60 posts

Re: The Difference Between CI and CD

#11

Post by greglindahl »

tomxor wrote: post #8
hinkley wrote: post #3

Earlier quoted context omitted.

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…

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?

Re: The Difference Between CI and CD

#12

Post by devonkim »

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

Re: The Difference Between CI and CD

#13

Post by jdlshore »

Ididntdothis wrote: post #7
jdlshore wrote: post #5

Earlier quoted context omitted.

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.

Sure, mistakes happen, which is why the process is typically automated. You have to go out of your way to merge faulty code. It's rare.

Not saying mistakes can't happen, but the person I was replying to didn't seem to be aware of this tooling.

Re: The Difference Between CI and CD

#14

Post by jdlshore »

tomxor wrote: post #8
hinkley wrote: post #3

Earlier quoted context omitted.

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…

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

Re: The Difference Between CI and CD

#16

Post by smcleod »

cottonseed wrote: post #15

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

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.

Re: The Difference Between CI and CD

#17

Post by cottonseed »

smcleod wrote: post #16
cottonseed wrote: post #15

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

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.

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

Re: The Difference Between CI and CD

#18

Post by colinchartier »

cottonseed wrote: post #17
smcleod wrote: post #16

Earlier quoted context omitted.

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.

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…

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

Re: The Difference Between CI and CD

#19

Post by adrianN »

smcleod wrote: post #16
cottonseed wrote: post #15

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

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.

Building a decently sized C++ codebase takes 20 minutes. Then you want to run tests on it.

Re: The Difference Between CI and CD

#20

Post by [deleted] »

hinkley wrote: post #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…

[deleted]
Post reply on HN