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

21–30 of 60 posts

Re: The Difference Between CI and CD

#21

Post by jpdel »

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…

Agree. Some faulty commits may go through. But then you strengthen your test suite to prevent similar issues to happen again, and so on.

Re: The Difference Between CI and CD

#22

Post by jpdel »

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…

Agree. CI=3-7 minutes. CD can be 30-60 if needed.

Re: The Difference Between CI and CD

#23

Post by gregdoesit »

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…

> If you insist on no errors on master ever you will kill throughput.

Unless you solve this engineering problem with tooling. At Uber, the full-blown CI mobile test suite takes over 30 minutes to run on a development machine (linting, unit test, UI tests - most of this time being the long-running UI tests, specific to native mobile). So we only do incremental runs locally, and have a submit queue, which parallelises this work and merges only changes that don’t break, into master. And we have one repository that hundreds of engineers work on.

It’s not an easy problem and the solution is also rather complex, but it keeps master at green - with the trade-off of having needed to build and maintain this system. See it discussed on HN a while ago: https://news.ycombinator.com/item?id=19692820

Re: The Difference Between CI and CD

#24

Post by jpdel »

adrianN wrote: post #19
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.

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

What about splitting it in smaller parts? And apply the CI process to each module?

Re: The Difference Between CI and CD

#25

Post by jpdel »

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.

We have a large Java monolith application. Builds ran for 30 minutes. Then we said let's only run the unit tests and critical smoke tests. The build time went down to 7 minutes ... on 12 CPU and 32 GB of RAM build slaves :) There's always a way.

Re: The Difference Between CI and CD

#26

Post by jpdel »

colinchartier wrote: post #18
cottonseed wrote: post #17

Earlier quoted context omitted.

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

Is this doing anything else than leveraging Docker multi layers caching?

Re: The Difference Between CI and CD

#27

Post by MaulingMonkey »

jpdel wrote: post #24
adrianN wrote: post #19

Earlier quoted context omitted.

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

What about splitting it in smaller parts? And apply the CI process to each module?

I've worked on C++ codebases where linking modules took over 10 minutes with a trivial change. Per config. Granted, that was with BFD, and I sped it up a good bit by switching to gold where we could... which meant our Windows MinGW builds still spent 10+ minutes per config, since those were stuck with BFD. But at least our Android and Linux builds were a bit faster!

But I like to touch common headers - say to document logging macros, and printf-format annotations to catch bugs, or maybe to optimize their codegen - and those logging macros are in our PCHes for good reason - so that still means rebuilding everything frequently. Which ties up a lot of build time (30-60 minutes per config per platform, and I typically have a lot of configs and a lot of platforms!)

Re: The Difference Between CI and CD

#28

Post by solatic »

cottonseed wrote: post #15

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

Maybe for software it's reasonable (tests should be parallelized more as you go above a 5m build), but for infrastructure it's ridiculous. No IaaS API responds remotely quick enough to bring up whole environments from scratch that quickly.

Re: The Difference Between CI and CD

#29

Post by adrianN »

jpdel wrote: post #24
adrianN wrote: post #19

Earlier quoted context omitted.

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

What about splitting it in smaller parts? And apply the CI process to each module?

Sometimes that can help, but don't forget that you still need to run integration tests on the whole thing.

Re: The Difference Between CI and CD

#30

Post by jpdel »

solatic wrote: post #28
cottonseed wrote: post #15

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

Maybe for software it's reasonable (tests should be parallelized more as you go above a 5m build), but for infrastructure it's ridiculous. No IaaS API responds remotely quick enough to bring up whole environments from scratch that quickly.

Agree. I would definitely put any infrastructure thing on the CD side though, as it is longer indeed.

You can test your software faster in CI using Docker compose. Something along these lines: https://fire.ci/blog/api-end-to-end-testing-with-docker/

Post reply on HN