Our great sponsors
-
Most people's CI issues can be solved in three easy steps.
1/ Get an actual, real machine. We run all of our CI for 10 devs out of a single 13900K / 64GB RAM machine, from a Jenkins setup that I've done over a weekend that has a single runner. 5-10 minute runs for PR validations (500kloc app, shitloads of tests, etc), 3 minutes for app builds. Buy it and host it yourself, or rent from Hetzner. You don't need a sysadmin for that. Machine is fucked ? Just restart it lol. Dependencies out of date ? Just upgrade your dockerfile, or your ansible setup and reinstall it all.
2/ Cache. Cache. Cache. Cache. Cache. It isn't hard if you're not looking for perfect. Nobody cares if sometimes, randomly you have one small module that rebuilds even though it shouldn't have: the beefy machine is here to make sure it takes 10 seconds anyways. All that matters is that you never have a cache that says even though it shouldn't. And to solve this: don't make the cache yourself. Your build tool either has it (Gradle, Maven, Webpack, etc), or there's a widely used tool that works (ccache, etc.). How do you store your cache ? Not on the build machine. Because that fucking sucks. Make it a remote cache (If using gradle, you can pay for enterprise if you're feeling optimistic, host a gradle remote cache yourself, or use https://github.com/androidx/gcp-gradle-build-cache and forget about it. The running costs of it have been well under a hundred dollars over a year).
3/ Less important, but know your build tool. I've spent a lot of time rewriting Gradle projects to avoid cross configuration, allow configuration caching, allow parallel configuration, etc. The same applies to everything else. Your build tool should be part of your knowledge.
-
If you're in the frontend space and are migrating to or already work in a Monorepo, I can't speak highly enough of NX[0] and their cloud builds. Very very fast. The caching algorithm they use is pretty nice and a little smarter than Turbo, and the distributed caching helps both in CI and developer machines.
My only complaint is I haven't been able to quite figure out how to make the developer machine cache independent from the CI/CD one, which has caused a couple of small issues we were able to work around.
One thing I have to say though, is I don't use NX plugins except for `@nrwl/jest`. I jsut use their Task runner capabilities. I found the plugins were a hassle if you weren't adopting the integrated[1] approach.
That said, it was easy enough to get up and moving with the task runner and we've seen major benefits. Did require us to think a little bit differently in how to run tasks in a parallel friendly way though.
[0]: https://nx.dev/
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
