61–70 of 81 posts
We run mostly Java backend and JS frontend, same story.
Tons of opportunities for optimization but company doesn't want to spend the time and devs appreciate the extra fuckoff time
The truth is that most slow pipelines "could" be optimized to run wildly faster, but that it is costly to do so. You may be able to find low-hanging fruit that affect the build-time significantly, but most of the optimizations to be done are very large projects, like updating thousands of tests to be isolated from the database.
I don't see how anyone can give you useful information without knowing more about the pipeline and the projects, and as everyone's pipelines/projects are going to work differently (I do web dev work, so pipelines are relatively simple, I can imagine that a game dev team creating Windows/Mac/Linux builds might have multi-hour pipelines though). Anyway as the question is "How Long Is Your CI Process", here we go! I hav…
Computing is cheap these days. If somewhere has a multi- hour build, that is a noxious build system smell. Run away. Or make sure the role involves you getting paid to optimize it. If a build takes 2 hours, and you work 8 hours days, it means you get four tries in one day to get it right? Four! That is no way to do modern computing. Things were worse back in the day (we compiled uphill, both ways), but we're not in t…
The latency of your CI process doesn't matter[1]. What matters is the development process - local build & test should be fast. Otherwise, with CI/CD, it's a continually-moving release train where changes get pushed, built, tested, and deployed non-stop and automatically without human intervention. Once you remove humans from the process, and you have guard rails (quality) built into the process, it doesn't matter if…
That's only if you can (and do!) test everything locally. Otherwise, you are still beholden to the CI system.
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/mocks, HALs, etc. are all good investments.
Figure out you can easily clone the CI tasks and run them locally, and then build tools for developers to do that easily for every change :)
It’s fast because the code has very few end-to-end tests... only eight or so. They take six seconds. The rest of the tests average about 200/sec, including narrow integration tests.
A lot of the drag on CI for complex projects is tests, which are hard to argue against. Complexity : need for tests isn't linear -- once you hit some critical mass of complexity where one person can't know the whole application, the need for tests skyrockets. I joined a company last year that's trying to solve this [1] by tracing tests so it can skip any whose dependencies (functions, environment variables, etc.) hav…
I’d be wild about anything that could trace our Cypress tests against our frontend and our nodejs microservices.
Istanbul used to be able to do this. https://istanbul.js.org/
The latency of your CI process doesn't matter[1]. What matters is the development process - local build & test should be fast. Otherwise, with CI/CD, it's a continually-moving release train where changes get pushed, built, tested, and deployed non-stop and automatically without human intervention. Once you remove humans from the process, and you have guard rails (quality) built into the process, it doesn't matter if…
Yes, if you don’t know what something is for, you’re not going to enjoy using it.