4 ms·

Show HN: DeltaCI: Bare Metal CI/CD with much faster builds

17 points by thinkafterbef 6y ago

thinkafterbef 6y ago
Hello HN, we’re launching DeltaCI, a cloud-hosted CI built with self-hosted CI performance. In our previous day jobs, we sometimes see ourselves keep hitting refresh on GitHub for 10 minutes just to wait for the test to finish then we can merge a PR. In every build run, docker build image has to be pulled, `npm ci` has to run although we haven't touched package.json. Even with an optimized caching setup, it's still painfully slow to pull a ton of node_modules from cache. Existing CIs also run their jobs on a Cloud VM which hardly go beyond 3 GHz, but our dev laptop can easily boost and 5GHz, then finish the same build in half of the time. We always migrated to a self hosted CI or build agent once the problem went beyond our tolerance. However it was always extra effort to set it up and maintain it. Since all existing solutions charge you on a per-minute basis, they literally have no incentive to make it faster for us. In the end, less build minutes = less revenue for them. So we came up with the idea of inventing a new cloud hosted CI to solve all these. Instead of paying AWS for the over priced VMs, we run your build jobs on latest Zen2, Zen3, 10th gen Intel desktop CPUs, as well as EPYC server cpus with upto 64 vCPU and 128G of RAM if you have builds which can make use of that. We developed our own VM hypervisor management solution based on libvirt. It will run your builds on the same disk image which are kept persistent between job runs, just like your local dev machine. We also made it easy for you to avoid repeating steps like installing dependency. For example, you can easily do this: steps: - run: sudo apt install rsync when: first_run - run: npm ci when.changed: "\*/package\*.json" Our system keeps your build environment persistent, and it also takes care of that rsync will be installed the first time you run the job, node_modules will only need to be touched when you actually have a dependency change. If you are building Docker images in your CI, then you also get Docker Layer Caching for free, since the building environment is persistent. We dog-fooded this setup for half a year, and it cut off our web applications build time of testing/e2e testing/releasing from 12 minutes to just under 4 minutes. We also benchmarked several open source projects, and also saw similar speedup. You find them at https://deltaci.com/ https://deltaci.com/ and check out the actual job runs. It's the first time we ever show this early stage product to the public, and it still has rough edges to be smoothed out. So we prepared a coupon code HACKERNEWS that’ll give you 99% off for 3 months. We’d love to hear your thoughts.
- c7DJTLrn 6y ago
  >It will run your builds on the same disk image which are kept persistent between job runs Unless I have misunderstood, this sounds like a recipe for a nightmare. One of the benefits of an ephemeral CI system is that you know any dependencies you install won't pollute future builds.
  - deleted 6y ago
    [deleted]
  - thinkafterbef 6y ago
    Modern package managers have already made sure this doesn't happen. Take npm for example, it only takes what is definied in package-lock.json, everything you installed in the past is cleaned up automatically. In fact, self hosted CI builders solely rely on such guarantee provided by package managers to produce correct builds.
    - c7DJTLrn 6y ago
      Package managers that come as part of a programming language are only part of the story. What about system packages? I'm talking about shared objects, headers, those sorts of things that you might install with apt or dnf. This is what trips people up the most when trying to build software, especially C/C++ projects.
      - thinkafterbef 6y ago
        Normally you install C/C++ libraries via system package manager like apt, or via your own script. So in deltaci's config it will look like this: steps: - run: apt install -y libxyz-1.1 when: first_run or steps: - run: wget http://libxyz-1.1.tar.gz && tar zxvf libxyz-1.1.tar.gz && cd libxyz-1.1 && make && make install when: first_run In our past experience, this is one of downside of self-hosted runners as you have to remove libxyz-1.1 manually. this is actually one of the reason why we wanted to make DeltaCI. It's currently solved like this, as soon as you replace libxyz-1.1 with libxyz-1.2, our system notice that the config has changed, it will execute it from a fresh environment instead trying to reuse previous building agent.

17 points by thinkafterbef 6y ago

Hello HN, we’re launching DeltaCI, a cloud-hosted CI built with self-hosted CI performance. In our previous day jobs, we sometimes see ourselves keep hitting refresh on GitHub for 10 minutes just to wait for the test to finish then we can merge a PR. In every build run, docker build image has to be pulled, `npm ci` has to run although we haven't touched package.json. Even with an optimized caching setup, it's still painfully slow to pull a ton of node_modules from cache. Existing CIs also run their jobs on a Cloud VM which hardly go beyond 3 GHz, but our dev laptop can easily boost and 5GHz, then finish the same build in half of the time. We always migrated to a self hosted CI or build agent once the problem went beyond our tolerance. However it was always extra effort to set it up and maintain it. Since all existing solutions charge you on a per-minute basis, they literally have no incentive to make it faster for us. In the end, less build minutes = less revenue for them. So we came up with the idea of inventing a new cloud hosted CI to solve all these. Instead of paying AWS for the over priced VMs, we run your build jobs on latest Zen2, Zen3, 10th gen Intel desktop CPUs, as well as EPYC server cpus with upto 64 vCPU and 128G of RAM if you have builds which can make use of that. We developed our own VM hypervisor management solution based on libvirt. It will run your builds on the same disk image which are kept persistent between job runs, just like your local dev machine. We also made it easy for you to avoid repeating steps like installing dependency. For example, you can easily do this: steps: - run: sudo apt install rsync when: first_run - run: npm ci when.changed: "\*/package\*.json" Our system keeps your build environment persistent, and it also takes care of that rsync will be installed the first time you run the job, node_modules will only need to be touched when you actually have a dependency change. If you are building Docker images in your CI, then you also get Docker Layer Caching for free, since the building environment is persistent. We dog-fooded this setup for half a year, and it cut off our web applications build time of testing/e2e testing/releasing from 12 minutes to just under 4 minutes. We also benchmarked several open source projects, and also saw similar speedup. You find them at https://deltaci.com/ https://deltaci.com/ and check out the actual job runs. It's the first time we ever show this early stage product to the public, and it still has rough edges to be smoothed out. So we prepared a coupon code HACKERNEWS that’ll give you 99% off for 3 months. We’d love to hear your thoughts.

c7DJTLrn 6y ago
>It will run your builds on the same disk image which are kept persistent between job runs Unless I have misunderstood, this sounds like a recipe for a nightmare. One of the benefits of an ephemeral CI system is that you know any dependencies you install won't pollute future builds.
- deleted 6y ago
  [deleted]
- thinkafterbef 6y ago
  Modern package managers have already made sure this doesn't happen. Take npm for example, it only takes what is definied in package-lock.json, everything you installed in the past is cleaned up automatically. In fact, self hosted CI builders solely rely on such guarantee provided by package managers to produce correct builds.
  - c7DJTLrn 6y ago
    Package managers that come as part of a programming language are only part of the story. What about system packages? I'm talking about shared objects, headers, those sorts of things that you might install with apt or dnf. This is what trips people up the most when trying to build software, especially C/C++ projects.
    - thinkafterbef 6y ago
      Normally you install C/C++ libraries via system package manager like apt, or via your own script. So in deltaci's config it will look like this: steps: - run: apt install -y libxyz-1.1 when: first_run or steps: - run: wget http://libxyz-1.1.tar.gz && tar zxvf libxyz-1.1.tar.gz && cd libxyz-1.1 && make && make install when: first_run In our past experience, this is one of downside of self-hosted runners as you have to remove libxyz-1.1 manually. this is actually one of the reason why we wanted to make DeltaCI. It's currently solved like this, as soon as you replace libxyz-1.1 with libxyz-1.2, our system notice that the config has changed, it will execute it from a fresh environment instead trying to reuse previous building agent.