3 ms·

From this perspective, the worst things I meet are setting up or tuning complex CI pipelines and developing infrastructure automation: a cycle can easily last m

From this perspective, the worst things I meet are setting up or tuning complex CI pipelines and developing infrastructure automation: a cycle can easily last more than half an hour and there doesn't seem to be an easy way to speed up things, really.

Retr0spectrum 10y ago
With a modular TDD approach, you could in theory test individual components very rapidly. I haven't looked into it too much, but I assume such systems exist.
- jerf 10y ago
  I have also often complained about this pain of CI systems. One of the problems is that the things you need to have a proper CI system conflict with fast build times. Proper CI requires a clean checkout, and a total compile fromscratch. If you're doing something in Docker, you ought to start your Docker process from scratch. If you're in a VM, you really ought to revert to a snapshot to make sure you're not accidentally accumulating un-CI'ed state. And so on. While in normal development you may have a very fast turnaround, a properly configured CI system needs to assume the worst, start from scratch, and build everything, in every combination you support. (You may also want a less accurate CI build that trades speed for accuracy and just does an incremental build of some particular aspect of the system. But that should be supported by the full CI I describe here.) Consequently, something that fails only 97% into that build process, and only fails on the CI server, can be very annoying to fix. But you don't really have a choice, because any hacky alternative is too risky. A CI system that has human intervention isn't a CI system.
- justifier 10y ago
  similarly, when in development i'll hack around slow CI times by storing the output of the most cycle heavy steps in the CI and on subsequent runs determine if i can just use the old stored values stead running through everything that said, i agree that there should be effort, or at least roadmap, to get CI compile times down to near native to play devels[sic] advocate we've had lengthy compile times on systems and native apps since time immemorial, it just seems that browser work has caught up in complexity and ubiquity.. even if some of that complexity can be blamed on negligent or lazy development

Retr0spectrum 10y ago

With a modular TDD approach, you could in theory test individual components very rapidly. I haven't looked into it too much, but I assume such systems exist.

jerf 10y ago
I have also often complained about this pain of CI systems. One of the problems is that the things you need to have a proper CI system conflict with fast build times. Proper CI requires a clean checkout, and a total compile fromscratch. If you're doing something in Docker, you ought to start your Docker process from scratch. If you're in a VM, you really ought to revert to a snapshot to make sure you're not accidentally accumulating un-CI'ed state. And so on. While in normal development you may have a very fast turnaround, a properly configured CI system needs to assume the worst, start from scratch, and build everything, in every combination you support. (You may also want a less accurate CI build that trades speed for accuracy and just does an incremental build of some particular aspect of the system. But that should be supported by the full CI I describe here.) Consequently, something that fails only 97% into that build process, and only fails on the CI server, can be very annoying to fix. But you don't really have a choice, because any hacky alternative is too risky. A CI system that has human intervention isn't a CI system.
justifier 10y ago
similarly, when in development i'll hack around slow CI times by storing the output of the most cycle heavy steps in the CI and on subsequent runs determine if i can just use the old stored values stead running through everything that said, i agree that there should be effort, or at least roadmap, to get CI compile times down to near native to play devels[sic] advocate we've had lengthy compile times on systems and native apps since time immemorial, it just seems that browser work has caught up in complexity and ubiquity.. even if some of that complexity can be blamed on negligent or lazy development