Travis CI acquired by Idera

It's also interesting how much Open Source is moving to Pipelines for just build services, regardless of where their code is hosted. The Python setup on Pipelines is really cool to dig into if you get the chance. I believe Python has been using it as the primary CI for their GitHub repo for bit now, and from what I've heard they've looked into using Pipelines to support a test matrix nearly as robust as their older BuildBot config.

We made a smilar decision in 2017. The reason was that our builds were stupidly slow because travis uses cheap instances. There was no option to fix that other by allowing more concurrent builds. Travis has no feature to actually allow users to have reserved instances of a particular type. Money was not the issue; the feature does not exist.

Builds were taking up to 20 minutes and with multiple team members doing prs, it was quite common to be stuck waiting for things to land to our integration environment. This slowed us down a lot and we fixed it by creating a build pipeline in amazon. In there we were able to pick one of their faster instance types and the exact same build ran in something like 5 minutes. I understand the team moved to gitlab pipelines after I left.

I was just discussing this with a guy that works at codeship, a berlin company that was acquired some time ago that creates build tools. He made the point that tools like that are getting replaced by deep pipeline integrations like provided by Gitlab.

There is a need for tight integration between build pipelines, version control systems, issue trackers, alerting, monitoring, cloud providers, kubernetes, etc. You can sort of do this partially but you typically have to deal with gazillions of SAAS solutions of varying quality that typically don't integrate that well and the devops related to that. E.g. making Jira aware of github PRs and build status in jenkins can probably be done but you are dealing with API tokens, access rights, and wonky webhooks, credit card payments, etc. The overhead of setting all of that up for every team is quite high and I've seen teams cut corners here because they have more important/interesting things to do. E.g. typical Jira setups have typically no meaningful integrations with either ci or version control systems. Even well run projects tend to have non trivial amounts of devops related time and cost to manage all this. Many projects simply start by copying whatever they did last time that wasn't completely horrible.

IMHO, this is potentially something MS could get right simply by creating deep integrations between e.g. Azure, Gitlab, and a few other things they own. IMHO, amazon is lacking a few things in their portfolio and it wouldn't surprise me to see them make a move either by launching or acquiring their own things. Google is another company that is missing a few essential things on this front.

Looks like a lot of people are having troubles with Travis CI in this thread, we do too.

With so many competing CI services out there now, it's kind of hard to keep using Travis. They've added Windows support, which is great, but it's ridiculously slow. (a minute to run on Linux, 14 minutes on Windows). And with these slow downs, you quickly run into parallel build (I believe the limit is 3 builds per user).

It's a decent point, but if I need Windows based testing, I'll get myself a free Azure Pipeline account and get Windows in CI from the same folks.

We also use travis + a monorepo and yeah TRAVIS_COMMIT_RANGE is broken. We end up just tagging successful master builds and generating our commit range off of that.

But yeah, so much of it is flaky, and the pricing is noncompetitive. Our current iteration has travis's docker client tunneling to an ec2-based docker server; it's both cheaper and faster and will hopefully make it easier to rip out Travis in the future.