2 ms·

Actually, CI is really one of the canonical reasons to use the cloud: short, bursts of load that can scale well (generally), but you don’t need 24/7. Using twic

Actually, CI is really one of the canonical reasons to use the cloud: short, bursts of load that can scale well (generally), but you don’t need 24/7. Using twice as big an instance means you need - roughly - half the time, which means costs stay about the same. I find that using regular cloud instances (eg EC2), with a custom runner for some CI platform (Gitlab, teamcity, whatever you prefer) is a really sweet spot. At QuasarDB, our C++ builds only take about 20 minutes this way, as long as we’re using a 128 vCPU instance. It’s a decent sweet spot for us.

tuyguntn 4y ago
Depends on company. Keep in mind we have 168 hours a week 1. company with <=20 engineers (or slow paced open-source) in one time zone. Except night time, you need constant running server for ~10 hours a day. (except weekends) = 50 hrs/week 2. company with 20 engineers in different time zones. CI running everyday except weekend = 120 hrs/week 3. if you have more engineers, then probably you need running CI every day. If you are a small company, in one region, it might make sense to fully rely on cloud, for other scenarios dedicated servers could be cheaper option. Highest cost is initial setup if automation is difficult.
steampilot 4y ago
I agree about the cloud having the potential to be a good fit for CI builds, but I don't think it's there yet as there is a time overhead with turning on and off a cloud VM. Ideally, we would have serverless functions doing this, but most cloud providers limit the run time for those. Another problem is that a lot of build systems are single threaded, and the chances of finding a server CPU that runs outperforms a 5Ghz home CPU are very low.