81–88 of 88 posts
On my repositories, setting up NPM now takes around 120 seconds instead of 20 seconds a month ago, time of npm run build has been increased from 7 seconds to 20 seconds...
The same build that took 2 minutes last month takes 4-5 minutes today
Earlier quoted context omitted.
> slow CI is probably the biggest engineering time killer in existence If you're at the size where slow CI negatively affects your projects, then you're big enough to own your own CI (at least the build agents). Remember that one-man projects don't need CI, and that CI for small (n<5) teams is almost never the bottleneck. These SaaS CI providers really target the open-source / small-team market and it makes sense tha…
> If you're at the size where slow CI negatively affects your projects, then you're big enough to own your own CI (at least the build agents). I think you vastly underestimate how much stuff people want to fit into CI and how quickly it turns into a big blob. I work as a freelancer helping not-quite-startups-anymore with things like CI speedup and tuning the database queries emitted by their ORM. You know, things whe…
I guess this is the same pricing model as CircleCI? I've always found "build minutes" to be a little bit of a vendor-favored pricing model. I really love wanting to do a release, and watching my CI provider take three minutes to pull down a 30MB docker image, or "npm install" running at dialup speeds. All while they're billing you per minute -- they make money by not investing in their infrastructure! I'd prefer to p…
As an example of what the opposite pricing model looks like, YourBase[1] charges a flat fee per build such that it's in their best interest to make builds as fast as possible. Because of this forcing function, builds are instrumented and cached down to the system call level deterministically, based on file changes. It's amazing what economic incentive can do. (disclaimer: I work at YourBase) [1]: https://yourbase.io
Earlier quoted context omitted.
As an example of what the opposite pricing model looks like, YourBase[1] charges a flat fee per build such that it's in their best interest to make builds as fast as possible. Because of this forcing function, builds are instrumented and cached down to the system call level deterministically, based on file changes. It's amazing what economic incentive can do. (disclaimer: I work at YourBase) [1]: https://yourbase.io
Would be great if you could make your pricing public. Call-me pricing immediately disqualifies a vendor from consideration for me, and I suspect I'm not alone.
Earlier quoted context omitted.
I think that's more of a comparison of different pieces of software rather than BYO or not. Jenkins is quite the beast no matter what size your projects. There are other fully self-hosted CI solutions, but Jenkins is the biggest one... the hardest one... usually the most fragile one... and for some reason the most popular one...
Yeah that's definitely a factor. There's part of it that's not related though – scaling out build capacity. Setting up a Jenkins build node is actually quite straightforward and reliable on the Jenkins side, similar to a BuildKite node for example, the issue is where is that node, how does it get provisioned, how is it managed, removed, etc. For us, it was a bare metal machine where we had to email a sales rep to get…
That'll do it. I'm using the Buildkite elastic stack, which took me about 20 minutes to start using and 4-5 hours to dial in to ideal settings (eg adding IAM to allow deploys from agents, getting the right size spot instances etc).
Earlier quoted context omitted.
> If you're at the size where slow CI negatively affects your projects, then you're big enough to own your own CI (at least the build agents). I think you vastly underestimate how much stuff people want to fit into CI and how quickly it turns into a big blob. I work as a freelancer helping not-quite-startups-anymore with things like CI speedup and tuning the database queries emitted by their ORM. You know, things whe…
Would you be willing to share some easy improvements that could be made? How can a large amount of tests run so much faster?
- Oftentimes the staging of the CI build can be improved. Devs often set up CI so that linters must pass _before_ actual tests are run. Run them in parallel instead and fail the whole run if the linters don't pass. This is even more important if there are multiple linters (perhaps for different sections of the codebase) and they all get applied serially before any of the tests start.
- Obviously, split up your tests as well so they can run in parallel. If you have a project containing both JS and backend tests, don't wait for one to start on the other. Many "bigger" languages also have something akin to parallel_tests (https://github.com/grosser/parallel_tests) that let you quickly set up multiple databases to separate transactions etc. It also provides tooling to remember the output of previous runs and uses that to equalize the parallel tracks of subsequent runs as much as possible.
- Cache as much as possible. This is a wider topic, but dependencies, docker layers and static assets can all be cached and correctly using this alone can hugely cut CI time. You don't want to know how many projects I've seen that don't have this set up correctly (or at all).
- Longer running projects can have hundreds of database migrations and applying them all to an empty database can take minutes. Big frameworks like Rails can dump the schema for you in a way that you can load in a second instead. Have a separate job that runs in parallel and applies all the migrations then verifies the output against the schema, all the other jobs load in the schema and use that.
Earlier quoted context omitted.
> slow CI is probably the biggest engineering time killer in existence If you're at the size where slow CI negatively affects your projects, then you're big enough to own your own CI (at least the build agents). Remember that one-man projects don't need CI, and that CI for small (n<5) teams is almost never the bottleneck. These SaaS CI providers really target the open-source / small-team market and it makes sense tha…
I disagree with this. Even a single project with 20-minute build times is enough to slow down or frustrate development. At the same time, I would not easily justify spending time managing CI infrastructure with my team of 6-10 people. Things may have changed since then, but the last time I self-managed build agents, it often lead to build jobs being tightly coupled to the build agent and installed software versions.…
Most people do not need CI until you have a separation of concerns (i.e. code from credential management) that are managed by different people/teams, and therefore all of the decisions cannot be made in a single room.
I do see being able to run test matrices across multiple OS or device options as a reason for smaller teams to adopt CI early.
Now Apple looks like a legacy platform similar to Intel.