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

31–40 of 60 posts

Re: The Difference Between CI and CD

#31

Post by pojzon »

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

How do you handle situations like that: multiple dvelopers added merge requests to queue, the changes they made are mutually exclusive (automatic rebase wont work). What happens when the first branch gets merged to master and next 10 are still in the queue ? How do you mitigate that to decrease development cycle ?

Lets just say in my company it also takes 30m to run tests and 4h to run them on merge pipeline with FATs and CORE tests.. Its way too long and highly cripples productivity.

Re: The Difference Between CI and CD

#32

Post by UK-Al05 »

gregdoesit wrote: post #23
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 may surprise you, but tests only help you find breaking changes. They don't guarantee it. To guarantee anything costs a lot.

Re: The Difference Between CI and CD

#33

Post by petepete »

cottonseed wrote: post #15

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

Our entire test suite takes about six minutes to run, we run all our tests in CI with Capybara. Our CD pipeline runs the same tests but against Chrome, Firefox, Safari and Edge. It takes more than an hour.

Re: The Difference Between CI and CD

#34

Post by glenjamin »

cottonseed wrote: post #15

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

/me raises hand

On our newer services there is a CircleCI pipeline which parallelises work and takes ~1-2 minutes on a branch, and maybe an extra minute at most on master - where it automatically deploys to production if the build is green.

If you make the choice to prioritise this from the start, it isn’t all that difficult.

Re: The Difference Between CI and CD

#35

Post by dewey »

cottonseed wrote: post #15

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

Our biggest Go project has a sub 3 minute build time including running a bunch of tests, staticcheck, pushing to registry etc.

It doesn't have to spin up any DB or things like that though.

Re: The Difference Between CI and CD

#36

Post by smcleod »

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…

Yeah, I totally agree with Fowler’s definition of CI more than I do this article.

In my case it wasn’t a need to spin up infrastructure as much as it was just pulling a few container images and starting them, the longest of the CI builds were if you were say loading and indexing test data from a database (container) into ElasticSearch etc... but overall moving images around and starting containers to build and test some ruby / python was usually around 1-3 minutes or there abouts.

Re: The Difference Between CI and CD

#37

Post by baq »

pojzon wrote: post #31
gregdoesit wrote: post #23

Earlier quoted context omitted.

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

How do you handle situations like that: multiple dvelopers added merge requests to queue, the changes they made are mutually exclusive (automatic rebase wont work). What happens when the first branch gets merged to master and next 10 are still in the queue ? How do you mitigate that to decrease development cycle ? Lets just say in my company it also takes 30m to run tests and 4h to run them on merge pipeline with FAT…

don't work at uber but have similar problems at my job and i'm quite convinced the problems you ask about are part of the 'not easy' in the OP comment. maybe they can queue whole branches instead of single checkins?

Re: The Difference Between CI and CD

#39

Post by s_Hogg »

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.

Re: The Difference Between CI and CD

#40

Post by danpalmer »

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.

Post reply on HN