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

Ask HN: How Long Is Your CI Process?

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 81 posts

Re: Ask HN: How Long Is Your CI Process?

#71

Post by nojvek »

2 minutes on GitHub actions from commit -> yarn install (90% we download from cache) -> webpack build with esbuild-loader -> netlify draft deploy for instant staging link -> smoke tests in parallel that hit the netlify url with real chrome browser (use browser less for that). Eslint, prettier, unit tests and tsc typecheck run in parallel.

Basically cache + parallelize.

Once PR passes, merge to master deploys in a minute. If something is wrong we can revert within a minute.

It’s joyful to build things when your tools are fast and reliable.

Re: Ask HN: How Long Is Your CI Process?

#73

Post by k__ »

jasonpeacock wrote: post #50
k__ wrote: post #41

Earlier quoted context omitted.

I could imagine that is only true for non-Cloud systems, where you can mock stuff locally.

The system I described is actually a cloud system, and we had both stubs and mocks of all our dependences (which is easy, because they were other cloud systems and we could easily stand up a fake service with the same API when doing integration tests, or switch to use local data when doing unit tests). We also performed testing against live dependencies but with test accounts to ensure that our stubs/mocks were accur…

I also read about tests that compare the mockups and stubs with the original implementations, but it sounded like overkill to write tests for your tests.

Re: Ask HN: How Long Is Your CI Process?

#74

Post by davewasthere »

Most of our builds (.net Core with a react front-ends) take around five minutes from push to having a release ready. Haven't really needed to optimise them at all. Roughly a minute for each of npm build, dotnet build, test and publish.

Deployment takes a little under a minute in total.

Worst one was probably a big Sharepoint application at one client's site. But that still only took about 12 minutes in total.

Re: Ask HN: How Long Is Your CI Process?

#75

Post by erikpukinskis »

My current job is a Node+React app that takes 8 minutes to go through CI. It feels subjectively a LOT better than my last job, which was Go+Node+React and took about 15 minutes, BUT...

The slowest part of the previous CI process was our integration tests on Selenium. And the new stack doesn’t have any of those (it just does unit tests in Karma).

And frankly, I think I’d take the 15 minutes with the extra security of knowing the whole stack is functioning together, over the speedup to my dev cycle.

But I feel a bit crazy saying that. In the end, the site doesn’t seem to go down due to the lack of integration tests. Maybe because we complement with manual testing. I never deploy without opening up the site in a browser anymore.

Re: Ask HN: How Long Is Your CI Process?

#76

Post by TheLocehiliosan »

jasonpeacock wrote: post #65
insulanus wrote: post #60

Earlier quoted context omitted.

That's only if you can (and do!) test everything locally. Otherwise, you are still beholden to the CI system.

Agreed! Everything the CI system does, should be runnable locally by the developer before it gets pushed. It's a belt & suspenders approach - when you push a change, you want to have already tested it to a high degree of confidence because the feedback loop from CI back to the developer is too slow. Effort spent moving all testing to the left supports faster iterations through shorter feedback loops. Creating stubs/m…

For too many people don’t get this. I’ve been pulled into projects that had a terrible pipeline and devs that were pushing commits and wasting so much time waiting to get feedback about very simple problems. This kills rapid development.

It took some redesign, but I was finally able to demonstrate how much could be done locally before pushes. Some just need their eyes opened up.

Re: Ask HN: How Long Is Your CI Process?

#77

Post by jasonpeacock »

k__ wrote: post #73
jasonpeacock wrote: post #50

Earlier quoted context omitted.

The system I described is actually a cloud system, and we had both stubs and mocks of all our dependences (which is easy, because they were other cloud systems and we could easily stand up a fake service with the same API when doing integration tests, or switch to use local data when doing unit tests). We also performed testing against live dependencies but with test accounts to ensure that our stubs/mocks were accur…

I also read about tests that compare the mockups and stubs with the original implementations, but it sounded like overkill to write tests for your tests.

Yes, at some point you get diminishing ROI :) We were OK with having the pipeline fail due to a change in the live API that our mocks didn't emulate, then we'd go update our mocks (and fix the code).

It happened infrequently enough that it wasn't worth the effort to automate the testing of the mocks against the live APIs.

Though honestly, for internal APIs owned by sister teams, this was usually due to a bug/non-backward-compatible change on their side, and we'd work with them to fix their APIs.

Re: Ask HN: How Long Is Your CI Process?

#79

Post by some_developer »

We've multiple PHP repositories but the longest one currently takes around 7 minutes wall time (that includes: tests, static analysis, code style and a few other misc smaller things). Scaling the phpunit tests is actually easy in terms of throwing money at it, as the suite of +15k tests can be diced and sliced to run segments in parallel (a bit of scripting + github action matrix). Billing time is around 40 minutes I'd say.

The frontend/TS stuff takes longer, usually 10-11 minute, where it's "truly building" and we can hardly parallelize this one. Or we lack the expertise to fix it probably.

At the moment though this is non-container environment; once we add building/deploying into the mix, I'd assume the time will go up a bit.

Re: Ask HN: How Long Is Your CI Process?

#80

Post by dmoy »

Centigonal wrote: post #52
dmoy wrote: post #42

Earlier quoted context omitted.

Yes, this is for the Kythe (née Grok) team at Google. We build a giant cross reference graph of the codebase. So - most teams don't have to build the whole codebase, but the Kythe team does. Here is a somewhat outdated talk given by our tech lead: https://www.youtube.com/watch?v=VYI3ji8aSM0 . That doesn't really get into any of the CI/CD stuff though, I don't know what if any of that stuff is publicly shareable.

This talk is FASCINATING! Not every organization maintains gigantic polyglot codebases, and it's interesting to see what kinds of challenges arise when that's the operational reality. I would never have realized the need for something like Kythe, because I largely work on codebases that are written in one language. I feel like a lot of what you all are working on might one day osmose nicely into something CI systems…

Thanks, I'll pass that feedback along to Luke :)

It is indeed a very interesting and somewhat unique problem space. Our current "killer feature" is simply powering the cross references for internal google code search / IDE / etc. But we're always thinking about ways to expand.

We are sort of trying to stuff it into CI/cloud stuff, though there are some hard problems around dealing with the enormous variety of build systems out there. It works okay in bazel/blaze, it can work for gradle or maven with a lot of work, and a few other systems. But, the amount of custom build tooling that projects use make it difficult to wire up the entrypoint for Kythe in a generic way.

Post reply on HN