Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The new pricing model for Travis CI

blog.travis-ci.com

Post reply on HN
Print view View original

61–70 of 88 posts

Re: The new pricing model for Travis CI

#61

Post by danpalmer »

solatic wrote: post #36
jrockway wrote: post #8

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…

> 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).

Strongly disagree. When I joined my current company, as an early engineer on a fairly new product, we had an 8 minute deploy time and I see that as a fairly critical component to our rapid iteration cycle that was critical to the company at that stage.

We had 3 engineers and had no time to spend on owning our own CI.

Re: The new pricing model for Travis CI

#62

Post by darekkay »

aaron42net wrote: post #59
darekkay wrote: post #51

Earlier quoted context omitted.

I've been using GitLab CI and Travis CI interchangeably. But the recent cut to 400 pipeline minutes on GitLab CI might make it less attractive than Travis CI, even after the current change. EDIT: Travis seems to take 10 credits per minute, with 1000 free credits per month. So it seems to be the least generous tool with 100 minutes per month vs 400 (GitLab CI) and 2000 (GitHub Actions).

Where did you see the "per month" for Travis? The 10,000 free credits are a one-time trial from what I can see.

This is from a Travis CI mail I got today:

> You have 1,000 credits left - these will begin counting down automatically as soon as you run your first build.

> You can use your credits to build on both private and open-source repositories using Linux, macOS, and Windows OS.

> 1,000 credits will be replenished automatically monthly. Additional Credits purchase is not available for Free Plan.

Re: The new pricing model for Travis CI

#63

Post by jnwatson »

solatic wrote: post #36
jrockway wrote: post #8

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…

> 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…

One man projects do indeed need CI. Test matrices can get large very quickly, and it is far easier to let that be somebody else's problem.

The open source Python library I maintain has over 30 instances in the test matrix of Python version x platform x implementations. I don't even have a Windows dev box handy. TravisCI and Appveyor take care of that for me.

Re: The new pricing model for Travis CI

#64

Post by softinio »

mariusor wrote: post #55
softinio wrote: post #23

Think the wiser options for OSS are Github Actions & Gitlab CI going forward. I have heard good things about Azure pipelines too. After travis-ci got bought and layed off a lot of key staff I did think the day would come where they will no longer will be the defacto choice for open source and I think this news confirms that day being today :-)

I think that for Open Source projects the better CI is still SourceHut. They're not currently limiting any of their resources for free accounts, relying on the funding from paid accounts to pay for their resources. I find this pay it forward model better than any other option.

Thanks for sharing! Good to know. Had not looked at their offering before.

Re: The new pricing model for Travis CI

#65

Post by WJW »

solatic wrote: post #36
jrockway wrote: post #8

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…

> 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 where it's easy to build up technical debt.

It's not uncommon for a team of 3-4 to build so many tests and add so many linters and whatnot that CI takes more than an hour. Often, some basic love can bring it down to ~5 minutes but many teams are so focused on building new features that they will not take time to sharpen their tools.

Re: The new pricing model for Travis CI

#67

Post by user5994461 »

jrockway wrote: post #8

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…

For reference, travis CI was sold to an investment company some time ago.

The strategy is 100% to not improve the infrastructure, fire all the developers to save costs, and milk money from existing customers for as long as possible.

Travis bought out https://news.ycombinator.com/item?id=18978251

Staff laid off the next month https://news.ycombinator.com/item?id=19218036

Re: The new pricing model for Travis CI

#68

Post by TrueDuality »

danpalmer wrote: post #60
danielheath wrote: post #13

Earlier quoted context omitted.

This is why I strongly prefer BYO-agents systems (github actions, buildkite, jenkins). I got our CI pipeline from 90 minutes to 10 minutes by running parts in parallel and applying lots more hardware. The cost is essentially nothing ($0.10 / build) compared to the time developers spend waiting. I currently use & recommend buildkite because they offer a preconfigured cloudflare template that does all of the hard parts…

It's funny, this is almost exactly the argument we used to switch to non-BYO systems – moving from Jenkins to CircleCI. We had Jenkins, but it required so much engineering time to manage, secure, upgrade, etc. Then when we hit scaling limits as our team grew, scaling it out to multiple machines took more time and cost a significant amount as we had to have capacity for peak time, which when all engineers are in one t…

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...

Re: The new pricing model for Travis CI

#69

Post by takluyver »

darekkay wrote: post #62
aaron42net wrote: post #59

Earlier quoted context omitted.

Where did you see the "per month" for Travis? The 10,000 free credits are a one-time trial from what I can see.

This is from a Travis CI mail I got today: > You have 1,000 credits left - these will begin counting down automatically as soon as you run your first build. > You can use your credits to build on both private and open-source repositories using Linux, macOS, and Windows OS. > 1,000 credits will be replenished automatically monthly. Additional Credits purchase is not available for Free Plan.

One of my colleagues got that email. It seems to be saying something quite different to the blog post and the billing documentation, and I don't understand how they fit together.

Even if the email is accurate, which is the better scenario, though, 1000 credits is 100 minutes of Linux build time (or 50 on Windows, 20 on Mac). Which is not much for any but the smallest projects.

Re: The new pricing model for Travis CI

#70

Post by danpalmer »

TrueDuality wrote: post #68
danpalmer wrote: post #60

Earlier quoted context omitted.

It's funny, this is almost exactly the argument we used to switch to non-BYO systems – moving from Jenkins to CircleCI. We had Jenkins, but it required so much engineering time to manage, secure, upgrade, etc. Then when we hit scaling limits as our team grew, scaling it out to multiple machines took more time and cost a significant amount as we had to have capacity for peak time, which when all engineers are in one t…

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 a machine added, then spend ~2 hours setting up firewall stuff with semi-manual Ansible scripts. Add to that minimum contract terms and difficulty cleaning machines, and it was a pain to manage.

Conversely, if you've got a reliable autoscaling solution of some sort, and your build manager is capable of poking that as necessary to scale up and down (possible with Jenkins, but hard), then this could be really easy to do and BYO may be feasible.

Having a CI provider give us ~unlimited pay-as-you-go capacity that needed no management on our end and was always a clean environment, that was worth a lot to us in engineering time.

Post reply on HN