Travis CI acquired by Idera | Hacker News Reader

Travis CI acquired by Idera

blog.travis-ci.com

452 pointsinvolans131 comments

Looking at Idera portfolio, I see Embracadero (Delphi developers for many years), Sencha (Ext.js), Assembla (was GutHub of Subversion era). So it seems like they buy companies and products that were big and very important among developersin the past, but not necessary leading the pack today.

I didn't think of Travis in that regard, though in a past few month I started to see Circle CI badges popping here and there for opensource repositories and anecdotally many internal projects at companies are moving to GitLab and their built-in CI offering.

Probably a good time to sell the company, though I'd prefer if they would find a better buyer.

That's exactly what they do, and the reason is that there is a long tail of subscription revenue that will continue to trickle in. They monetize that very well (for the owners)

This suggests that, at least from track record so far, for products in their portfolio one should not expect much more extensive development or innovation, they're just counting on the long-tail of revenue trickling in?

Some products are feature complete and since they are looking at long term earnings they won’t sunset the project which are two big pluses .

as a former customer of idera (and a customer of their competitors), even their core products don't really get much ongoing development attention. they _were_ quite good for what they were, when they were current. after a while, though, they do just become subscription streams.

This is not true. They make strategic investments to keep their products relevant. They are not making the next Google/Amazon/Apple, just running a business effectively.

Honestly, for enterprise users that is a good thing. In the hands of a company like Idera we can be reasonably confident that Travis will not disappear anytime soon. Under independent - or forbid Oracle / Google stewardship - that is far less certain.

Travis will likely slow rot under Idera, looking at how its owned by a private equity firm. This is better in some ways than getting Our Incredible Journey'd under someone like Google.

As an employee of Embarcadero I can tell you they do invest in new development. Delphi has received a number of new features and updates since Idera aquired us. Could they invest more? You can always invest more, but it is important for the long term that the company and products continue, which Idera seems good at.

* this is a comment from me personally and not an official company statement.

Do you think they will have enough money to fix gazillion of RIO bugs? Cause i have a feeling that Delphi is is getting out of tracks and nobody cares about it anymore? But i wish i am wrong since i like it very much.

Kind of off topic to this discussion, but yes.

I completely agree. Not making a judgement on the model, it is what it is.

Yeah, I've been seeing lots of people switch to circle-ci or gitlab over the past year.

Not totally sure why. Travis does what I need and I know how to use it, and I don't particularly want to learn something new for CI myself, I just want to code!

CircleCI has a free tier for private repos, same with Gitlab.

The private repo pricing was what drove me to try an alternative to Travis in the first place. The cheapest private repos plan is $70/mo now and, if memory serves, when I looked into it previously it was >$100/mo.

Fine for startups I guess. For the use case of someone who wants a CI server that, say, runs tests on their Project Euler private repo it's a no-way-no-how price point.

I assume they've thought this through and it's done purposefully. Still, side projects tools are a gateway to real project usage.

Personally, I've seen growing stability issues. Builds are failing for no apparent reason and work fine after a manual restart. Circe CI was the next free service to try.

Worth plugging https://sr.ht I guess. It's free for now and it's going to be very cheap[1] when it does start requiring a subscription. In addition to supporting the open-source developer who gave us things like Sway, you'd also be able to build on platforms like RISC-V, which I don't think anybody else offers.

1 - As little as $2/month, apparently.

No Windows or macOS support though. Also Git integration isn't as straight-forward as it is with Travis/Circle CI.

FWIW, I'm currently using Circle for several builds, and am actually looking at alternatives now. The web interface has been falling over (which is highly disruptive to developers when they can't look at build results and trigger deploys, etc).

Circle has some nice features (especially easy artifacting and splitting rspec tests based on historic run-time) but it's not enough to overcome the lost momentum and productivity of being unable to reach the web interface.

At my company we've just finished migrating our Android builds from CircleCI to Buildkite (we did the iOS migration in December).

I've been very happy with Buildkite so far. The web interface fits my mental model of how things should work much better than CircleCI's ever did.

Our primary reason for switching was CircleCI's unpredictable and high costs on the iOS side (per minute billing combined with slow builds -> monthly fees in the price range of a new Mac mini).

Our Android builds are now about 10 times as fast at the same price.

The savings and the performance benefits are of course wholly due to the bring-your-own-build-machines approach that Buildkite takes. I don't see that as much of a hardship, though, especially since CircleCI 2.0 removed a lot of the "it just works" magic in favor of your own build scripts and Docker images. Preparing the build agents is not significantly more work.

Buildkite is a dream. Their technology is spot on, and it's changed the way we develop/integrate/release.

The main reason why we moved to CircleCI was due to the rising test flakes and outages in TravisCI. Also, TravisCI comes with a lot of crap pre-installed which can be a pain sometimes. With CircleCI you can provide your own custom Docker image for running the build. If the build fails there is even an option to SSH into the build to debug. This issue has a lot of details on what it takes to migrate an open source project from Travis CI to CircleCI if you are interested. https://github.com/zulip/zulip/issues/7748

You can ssh and debug a travis build as well

But only on travis-ci.com, not for Open Source (.org) IIRC.

You do realise that the two platforms are being merged, with .org projects being migrated to .com?

(Disclosure: Travis CI Employee)

We can do it on .org as well! Just need to reach out to us via email to enable it (as well as the instructions, as it requires a manual API call rather than a UI Button.) And, as Involans also mentioned, we are merging the two together.

support@travis-ci.com And we'll set you right up with debug mode. :)

There used to be a catch, though, don't know if it's already fixed. If you use this ssh debugging feature you make your secrets world-accessible (anyone can connect to ssh and grab them). This was one of the reasons why I switched to CicleCI, actually (besides their Workflows).

Yes, it is indeed correct that if somebody grabs the ssh command with the key while you are debugging, it is accessible. It's something that we want to address in a better way, but other priorities are present right now (build image updates, performance improvements, some new features that we haven't announced yet.) Still, the feedback is appreciated!

And as far as I can tell, CircleCI doesn't seem to support Windows yet.

For one of my projects, I have TravisCI building release binaries for Windows, Linux, and macOS.

We usually use CircleCI at my company. I never realised how good I had it until I had to use Travis at my current project :)

To give an example: we have a monorepo and it's impossible to only run the tests of the project that has been updated. Even if you're ready to hack around with git. Even if you're ready to hack around with Travis internal functions. Because TRAVIS_COMMIT_RANGE is just broken.

And your argument "people switch to circle-ci, not sure why, Travis does what I need and I know how to use it" doesn't really make sense, other people would say that CircleCI does what they need and they know how to use it

Don't you need to do the same hacking within CircleCI?

I do, but at least it is feasible (at least I think, never actually needed to do it). With Travis, even being willing to hack around, I just didn't manage to get it working at all

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.

Not a bad idea but travis only does a shallow clone, do you unshallow it? Doing a `git fetch --unshallow` was slow, and hanging forever about one time out of 5 when I tried a few weeks back

Yeah, in this case we did though I can see a lot of instances where the benefits don’t outweigh the costs.

We switched from Travis CI to Circle CI because Circle CI was (a) significantly faster and (b) a little cheaper

Travis is nice, but the cost always make me look at Semaphore or Codeship.

curious though - what event / issue motivated you to even start looking for another solution?

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.

GitHub. Microsoft does not own GitLab. :)

Heh, similarly named companies. You get my point though ;-)

GitLab is an LLC, GitHub is what's owned by MS

GitLab is an Inc. :)

Still independent.

I feel dirty for saying this but Azure Pipelines is the service that is tempting to me because of the power of its file format (variable substitution, conditionals, template tasks and steps).

No need to feel bad, it's a great product! I've been using Azure DevOps for a while now, and it's what I use for anything not OSS (I prefer GitHub for that, and TBH it's what others expect)

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.

The onboarding process of Pipelines is very smooth once you manage to sort the OAuth/account stuff out. And they actually have helpful docs to boot.

Curious if anyone has used Azure Pipelies with Rails projects and has a review.

(Yeah, I know, all these CI things are hypothetically platform agnostic, but then there's reality, different platforms-under-test have different sorts of problems which become priorities for the CI platform to smooth out and make just work, or don't).

I think that you want somebody who's unbiased to answer this from their perspective (I'm a PM for Azure DevOps, so I'm pretty biased). But I've built out Azure Pipelines for many platforms, including Ruby and RoR with a lot of success. Feel free to drop me an email (my HN username @microsoft.com) and I can point you to some pipelines.

Cool. The trick is, I don't want to "build out a pipeline", I just wanna write a handful of lines in a single config file and be up and going, which is what travis has given me.

But Azure is def on my list to check out!

Haha, yes, sorry for making it sound bigger than it is. If you just want to do some build & test validation, it should just be a single yaml file. Not identical to Travis but close. We even added some getting started documentation if you’re familiar with Travis. https://docs.microsoft.com/azure/devops/pipelines/migrate/fr...

I never believed I'd ever pick a Microsoft product over anything else.

And yet, here we are... Azure Pipelines

Edit: VS Code too

We use Azure Pipelines for https://github.com/web-platform-tests/wpt with some help from friends at Microsoft, and it's a great product!

It's very "power user" in that it's easy to get lost amongst all the options, but nothing else I've tried has the same breadth of OSes and ability to have one job depend on another in intricate ways. And, 10 free parallel builds, including macOS!

I’m quite liking azure for now and most of my company’s foss projects run there. But. Reason for getting lost is abysmally bad documentation. Yeah, all that I need is there but it’s structured so so bad.

Also, hosted agents have small inconsistencies that make the pipeline to have ton of do this on Linux but not in OS X or windows and so forth...

And I have been wondering if Circle-CI will be the next battle between Microsoft and Google.

I've chosen CircleCI over Travis for some projects because CircleCI is free for private repositories (to an extent). Travis is only free for open source, and is slightly more expensive for similar resources.

Of course that doesn't explain why open source projects would switch, but it could just be a mind share thing.

I've actually seen (and need to do so myself) a few migrate to(or move even more into) Travis because they've added Windows builds. AFAIK they're the only hosted CI that offers Linux, Mac, AND Windows builders.

Azure Pipelines was the first one, and would probably have a better service overall if they had better documentation and supported more languages/environments.

I’m a product manager on Azure Pipelines. Can you tell me more about what’s missing in the docs and language support to make it better. Email works as well jepling at microsoft dot com.

Azure DevOps (formerly VSTS) in general moves really quickly, relative to everyone else. At least it feels that way... the multiple names to search for (vsts, tfs, "azure devops") also makes it hard to find stuff in general searches. Often the results are prior versions, and it's still hard to figure out.

I dread when I have to tweak things. I do appreciate the service(s) a lot though. Pipelines is one of the better CI/CD platforms I've ever used anywhere. It's just, like you said, sometimes hard wrt documentation.

Ah, I'll have to check it out

FWIW, as someone in the process of trying to set up an Electron app to generate Linux / Mac / Windows builds on CI, I found Travis's Windows support to be unusably slow and flaky.

I hear Appveyor and Azure Pipelines are the two most usable Windows build systems; I'm quite happy on Appveyor.

> I hear Appveyor and Azure Pipelines are the two most usable Windows build systems; I'm quite happy on Appveyor.

Doing better than me. Only inertia keeps me on Appveyor. Once I have time to look into Azure Pipelines, I'm off Appveyor for my Rust projects.

At least for open source, Appveyor builds are serial (across all of my projects?) and you have to (had to?) go through hoops to setup cron triggers.

For serial builds, it is so bad, half the time I give up waiting and just submit.

For cron, I only care about scheduling about once a month or so to double check none of the tools I rely on break so contributors aren't the first to see them and have a negative experience.

Looks like they bought Froala too, which is the best html editor we've used so far.

What does the $144 Froalo offer that open source alternatives don't? Serious question. The Froalo site is not convincing at all.

Have you tried the demo? It's incredibly feature-filled and acts like a real editor with drag/drop, content embeds, etc. while still producing clean HTML output.

It's not as fancy as the abstracted editors that have their own non-DOM format structure but they usually are missing many other features.

The pricing has increased and the hobby plan probably isn't worth it but the product itself is good if you need an editor.

I've switched my personal projects, and my employer has switched to Circle over the past year. Circle's dockerized strategy for building up your CI/CD platform means that they support the new version of X nearly the day it comes out. Historically Travis has been very slow at this. Their support for Postgres 10 was an embarrassment (https://github.com/travis-ci/travis-ci/issues/8537). It's also vastly easier to parallelize your test suite. With Travis we had to install a third party gem to run our Rails' across many nodes. We also had to hand-manage balancing. With Circle we simply followed the docs, and we're off to the races.

I work on knapsack gem to split tests across parallel CI nodes. To do optimal balancing I developed a dynamic test suite split with Queue approach.

Here is example for Travis CI https://docs.knapsackpro.com/2018/how-to-run-travis-ci-paral...

And this is the graph showing the difference if you compare knapsack_pro dynamic tests split with what CircleCI does which is basically only time-based split. https://docs.knapsackpro.com/2018/improve-circleci-paralleli...

+1 for Knapsack. It's cumulative savings for our CI/CD has been tremendous.

I've also, anecdotally, started seeing more Azure Pipelines badges on open source projects, too.

Indeed - from the Azure Pipelines side of things, we started seeing a fair number of open source projects move some of their workloads over to us when we announced unlimited build minutes for open source projects. (I'm a PM for Azure DevOps.)

From my perspective, it's been interesting to see how people do. Some people bring all of their builds, of course, but some people split it up so that it's a mix of Azure Pipelines and Travis (or, of course, something else). Some people are bringing one or two platforms over - maybe they had Travis working as their build validation system, but it was doing Linux builds. So adding Windows builds with Azure Pipelines made sense. Or they wanted to do macOS or iOS builds, so they started building on our macOS build agents.

Anyway, I'm happy for Travis and I'm glad to see that they're excited about this acquisition. I can speak from first hand experience that running builds for open source projects takes a lot of resources. So I trust that this will help them make sure that they're in a position to continue helping out the open source projects and communities.

I prefer TravisCI to CircleCI, but I can get CircleCI on a private repo with their free plan. I honestly don't prefer CircleCI's UI/UX, it frequently is missing or caching info and I have to hard refresh the page to get things to work.

Is there a good read somewhere about Travis CI vs Circle CI vs gitlab ?

Disclaimer, I am a GitLab employee, but we have some docs on this that you can find here:

GitLab vs CircleCI: https://about.gitlab.com/devops-tools/circle-ci-vs-gitlab.ht...

GitLab vs TravisCI: https://about.gitlab.com/devops-tools/travis-ci-vs-gitlab.ht...

Circle CI has been steadily taking marketshare away from Travis for many, many years. And in my personal experience, mostly because of Travis' slow pace of improvement. Using containers for testing blows away performance on Travis for comparable tasks. Travis had made some improvements this last year to their workflows, configuration, and platform, but too little too late. My experience in dealing with their customer service (we did have a paid plan for some time) and customer feedback (feature requests, pleas for fixes, etc) was also quite poor.

I'd moved to Circle CI two years ago, and the only tasks/projects of mine still running on Travis are those which are deprecated, in suspended animation, or abandoned. For myself and my immediate peers, Travis is obsolete, and they did it to themselves. With Azure pipelines now a thing (and also far superior to Travis) I see another slow, slow death of a pioneering service.

Does Circle-CI offers Mac runner for public/open-source projects? This is the reason I haven't been able to migrate from Travis to Circle-CI for all my projects, I have an open-source Electron module that I need to test cross platform so Travis covers Linux and Mac and AppVeyor for Windows.

I was able to acquire that ability by emailing them and explaining the open source need. They were quite reasonable.

It's worth noting that Travis also supports windows builds now. Which to me is a HUGE value proposition over CircleCI.

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.

> Does Circle-CI offers Mac runner for public/open-source projects

Yes, but you have to ask them to enable the thing. I used them for ArchMac before I migrated to GitLab. I am contemplating moving back to GitHub and CircleCI, unless I can get my hand on some decent hardware again to run the CI builds.

> Travis is obsolete, and they did it to themselves.

This is sad, but the conclusion I have come to over the last 3-4 years as well. It was anybody's market 4 years ago, but through a sustained pace I think CircleCI have out-executed Travis consistently.

The thing I find interesting is that, looking at Semaphore CI who used to be far behind Travis, they are now biting at the heels of CircleCI with their 2.0 iteration. From what I understand they are not venture backed and are a smaller team, and yet their product is starting to look like a real competitor. To me this says that Travis just failed to execute well enough, rather than Circle having more money (although that helps).

Thanks for mentioning Semaphore, cofounder here. Yes, we’re 100% bootstrapped and in this for the long haul. It’s really all about execution. We built 2.0 in a timeframe in which we’d previously ship one or two features. Of course years of domain experience help, but everyone from Fred Brooks to DHH is right — adding more people won’t help build a better product faster.

I love Semaphore. I remember getting a handwritten personal note and an informal invitation to visit in Novi Sad a few years ago. While that doesn’t say anything about the “tech” it does show that they are real people that care deeply about users — even fairly insignificant ones like me. That it’s a bootstrapped company with a really great product made me happy as well.

I wouldn't mind trying out Semaphore for some open source projects. On the community open source page [1], from what I understand, you offer a free service, but the pricing page [2] says that it's not free yet?

[1]: https://semaphoreci.com/community/open-source

[2]: https://semaphoreci.com/pricing

If you don't mind logs and project pages not being publicly visible, you can start using the Semaphore 2.0 free tier with your open source project. If you run out of credits send a support request and we'll increase.

That community page is outdated and referring to Semaphore Classic (1.0) and 2.0 will be getting proper open source support soon.

Semaphore v1 has been great and very simple to use. Huge fan of those guys. Bootstrapped, extremely friendly, helpful and competent. We’ve been using them since 2012.

v2 definitely looks promising but they’re not sunsetting v1. Lots of respect for that as well.

Edit: at the risk of sounding like a fanboy (I guess I am), they also grandfathered us indefinitely on the same price plan we signed. Not many companies do that sadly.

I’ve had a similar experience. It seems like Travis rested on its past reputation for a long time and Circle slowly eroded their lead with a much better platform.

Circle was way ahead of Travis in their docker implementation. The Travis docker stuff always felt like a hack.

Once I started moving more projects to Circle, most of the developers on our team were much happier on Circle.

In case anyone from Circle CI reads here: I haven't had the need for a hosted CI so far so this is all new to me. I looked at the Circle CI homepage and they have a video on the homepage "See how Circle CI works". Try watching that without sound. It's useless. I'm not sure why anyone would create a video like that.

This is another homepage that already assumes that everyone knows what it does and is no help to people unfamiliar with it.

While I agree with you that the homepage doesn't do a good job explaining what Circle CI is to someone unfamiliar with CI, your criticism of the video doesn't make much sense to me. The video has a voice-over explaining what Circle CI does, and includes subtitles for when you don't have sound.

That's true. But if all the information is contained in the text. Why not make it a text I can read at my own pace instead of forcing me to watch it through a video at no additional benefit.

https://circleci.com/product/#how-it-works

For what it's worth, this video is an ad - I have seen it (at least the first five seconds of it) at least 20 times prior to youtube videos [1].

So I guess they wanted a YouTube add, so it needed video and once they had paid to make that said hey why not stick it on our homepage? Or something like that.

It could have also gone the other way: as a useful video describing how things works, and then it got a second life as an ad - but the former path seems more likely.

---

[1] I'm not sure why they are targeting me so heavily, but I see this ad more than any other, by a large margin.

I wonder if this kind of thing happens so often in software because we get fixated an idea of how a problem should be solved and lose sight of solving the problem. Better solutions that don't dovetail with our model of the world get discounted until the evidence is overwhelming.

On a tangent and just because these discussions almost never happen; Jfrog has been my most terrible support experience. We have an OSS and paid plan and I expect 4+ days before hearing back from them. If/when are repos experience an issue we would be dead in the water. I have even tried calling their emergency contact number with no answer or call-back.

Ouch, that's bad, shouldn't happen and usually doesn't happen. Ping me in DMs on Twitter (@jbaruch) or by email (jbaruch@jfrog.com) and I'll investigate what happened.

I've been worried about travis' lack of urgency in dealing with the fact that the existing travis-ci.org github hooks used for open source products are going to stop working in a week or two...

https://github.com/travis-ci/travis-ci/issues/9745

Now bought by a private equity firm, which usually doesn't indicate lots of innovation or an increase in quality on the way.

I wonder if I should be worried and start migrating my projects. I really liked travis for so long.

Hey there,

(Disclosure: Travis CI Employee)

The migration from GitHub hooks is actually just about complete. You can see the changelog entry here: https://changelog.travis-ci.com/migrating-from-github-servic...

Apologies for the lack of public updates on this!

Thanks! Good to know.

Really kind of down to the wire though, eh?

It would be really disastrous if the deadline were to be missed, but even if it goes smoothly in the end, how it's been handled does not inspire confidence. One documentation page still says "The migration was planned to start at the end of Q2 2018, but has been pushed back. We will announce a new date as soon as we are able." --https://docs.travis-ci.com/user/open-source-on-travis-ci-com...

It's definitely not ideal, but it is less dangerous and close-to-the-wire than it sounds. It's actually separate from the migration to .com - which is something we haven't been great at communicating, and after talking it over yesterday, we're going to post something to clarify it a bit further. (Even working here, I was personally rather confused about it, and was running around yesterday chasing people down for answers.) The short of it as follows, though:

GitHub Services are going away. This is what .org relied on previously, and we are now mid process of getting everyone moved over to Webhooks instead. So, .org will rely on Webhooks instead.

In the meanwhile, we are still working on getting everyone migrated over to .com as well (which uses GitHub Apps), but that's unfortunately been a bit of a trickier beast than expected. We're still very much working on it, though. Hope that clears it up a bit!

EDIT: We are updating the docs to reflect this. :)

Oh I see.

Yes, I thought the two migrations were the same thing. I think maybe y'all thought they were too until recently when you realized you weren't gonna get it done in time?

After all, if the migration to .com really _had_ started in Q2 2018, it probably would have been done long before Github Services went away, and you wouldn't have had to fix .org like you do now. Maybe that's what travis was assuming originally... if at some point that changed, it wasn't communicated clearly, as you acknowledge.

I also was thinking in terms of "the GH api that .org uses that's going away", and "the GH api that .com uses that isn't." I didn't realize there are actually THREE separate GH integration APIs involved? "Github Services", which .org used to use, and is going away. "Github Webhooks" which .org will use soon. And "Github App", which .com uses?

It's all very confusing.

But that's why it's incumbent on y'all to explain it. When we get a warning from Github some ~8 months ago that travis is using deprecated API's that will go away on Jan 31st, and travis is unable to tell us anything much about the schedule or plan for doing something about that until Jan 20th, and it's still pretty vague... that's either a failure of planning or failure of communication or both on travis' part. None of us, your customers, would wait until the week before drop-dead to remove a deprecated dependency in production software when we had 8 months notice... unless we were in some kind of crisis.

On Jan 31st we will see if travis.org hosted projects keep working without interruption...

(I also don't understand why I can't _choose_ to migrate my app from .org to .com at any time. _Some_ of my peers _have_ migrated their apps, with self-service web UI, but my projects it won't let me. NEW open source projects can be on .com for free. But my existing ones on .org are stuck there waiting on nobody knows what, I don't think I can even delete the project and create it anew on .com... If I'm explaining this unclearly, yes, right, exactly! I know I don't even understand what's going on, and don't want to have to, I just want it to work!

Anyway, I'm not blaming you personally, but trying to give you a flavor of one part of leading to loss of confidence in travis, which I historically have loved, for me personally. And part of that is I used to consider travis _really good_ at communicating what was going on, which as we all know is something developer-customers often value.)

Yep, totally agree that it is very confusing. Definitely appreciate all your feedback (and not taking it at all personally!) and it helps immensely. I'm gonna try to skip the PR speak, but I'm hoping we'll be able to regain that confidence when we make the right changes. :)

Interesting. All I can tell from Idea's homepage is that it likes to acquire companies: https://www.ideracorp.com. It looks like it's just a private equity firm (or the acquiring arm of one, since it's owned by TA Associates).

I've never heard of any of the software in Idera's brand portfolio. I wonder what the cultural change is like internally at a company joining the umbrella of a private equity firm.

Seems about right. They have acquired a lot in the last 2 years.

https://www.ideracorp.com/brands

and

https://www.ideracorp.com/news

All my ex coworkers at Sencha have been "promoted" then immediately laid off after the acquisition (2-3 months). Their business model is to milk long term support contracts, I wouldn't expect Travis to be relevant anymore (if it was before).

Yeah, one of their "brands" is also called Idera, and I worked there for many years prior to the acquisition. But, yeah, just shortly prior to the acquisition, most of the dev group were let go to improve the bottom line, and a small group of 4 or 5 devs were kept and promoted to manage an outsourced team in some other country to continue developing the products. The atmosphere post acquisition was different, though, being at the company while it was growing, the culture also shifted as we grew from scrappy startup to "we are now in a high rise office tower" corporation.

And then from a high rise to a shitty office space where you could regularly see hookers on the elevators and at least while I was there the bank at the bottom was robbed at gun point twice.

Sounds so exciting! :^)

My last job was for a small company making a APM tool. We were bought by Idera and they fairly quickly laid off nearly everyone.

We were cautiously optimistic when the purchase happened. Idera had just purchased a pair of similar applications with different target audiences, so we thought the products would stick around and there would be a lot of work to do integrating everything. We were right about that (they're all still separately available) but Idera didn't have us in mind to work on it.

Our PM went to Idera's offices and found that it was basically a sales centre and that all the development was outsourced. A week or so later they came and laid off a third of the company. Within 3 months of the purchase, the only employees left were our PM, 2 sales reps, and 2 support.

I can't speak to the software, but I don't like the chances of anyone employed by Travis.

Curious to what this means for the Berlin tech scene in general. Travis was certainly one of the trailblazers and a high visibility local startup (next to probably Soundcloud).

European tech scene is completely dominated by US companies, this one company (unknown to people outside the tech scene) won't change that at all.

Why does it matter whether or not a tech company is known by people outside the tech scene?

Yes, I have fond memories of hanging out in their offices above beta house. Amazingly welcoming bunch of people and one of the best things about the Berlin tech scene for me. Hope it works out well for them. I know they were never in it for the money but they deserve a decent payout for their years of commitment.

And with that I declare this product dead... Idera is the last stop to squeeze cash out of a company.

Expect layoffs and all future work to be outsourced via fixed cost development to lowest bidders (mostly in India). Also expect a big sales push for multi year contracts.

Nothing wrong with India, just that companies like Idea don't like to have developers on payroll, and the ones that do write specs all day long.

Lots of mention of CircleCI and Gitlab as the reason for Travis' downfall, which is very true. I also think GitHub announcing GitHub Actions[1] may have been the final nail in the coffin.

I think GitHub Actions will become a major force in the CI market in short order, it has so many things going for it

a) Everyone already has an account and lots of code already lives there. One less extra thing to worry about.

b) I trust MS/GitHub with my Cloud secrets more than I trust the various other CI providers.

c) The financial backing of MS to provide a significant free tier

d) The fact that actions can so easily be shared on GitHub is a killer feature. More are more projects/companies will build actions for their end users.

1. https://github.com/features/actions

The first startup I was at was acquired by Idera. They started by trying to replace everyone in the dev team with remote contractors. I cashed out and left as soon as possible.

I would have loved to paid Travis CI for my personal private repositories I wanted to kept private, that I push to maybe 1-2 times a night on a good week. Setup is a breeze, interface is simple and straight to the point, integration works. But they priced their "Ideal for hobbyist projects" plan way out of budget for any hobbyist who just wants somewhere to run some code. $70 a month!? Make it $15, maybe $20 and you got yourself an annual subscriber.

Loved Travis support over the years. I wish them the best.

Though lately ruby-travis cli has been broken for me on Arch, and with their YAML changes & associated complexity... I'm starting to look forward to Github actions.

Lots of issues with Travis CI feature velocity as well. Most of the other pain points others have mentioned I have felt. Random build failures, network issues, and etc.

A particular issue is the PR merge-commit builds. Between stages a merge/push into master can change the merge-commit! This means code between stages can diverge. You may build an artifact in one stage, then run an out-of-date test suite against it in another. Known issue for years, had an employee acknowledge months ago on the community forum then.. Nothing.

Another pain point that is not unique to Travis, is the lack of true "pipelines". Inter-project builds are a complete DIY crap fest. Coupled with roll-your-own artifact storage and retrieval.. Self-hosted solutions like Bamboo and TeamCity(Bamboos superior IMHO) are light years ahead of the SaaS solutions I've viewed.

Test report analysis is another big feature missing from most. Would be good to be able to visualize and report on tests. I was almost considering this being a valid stand-alone SaaS idea because nobody has it!

I believe the future of our integration/system tests will be build on codepipelines or the like for scale. Travis or CircleCI will be the public facing component.

Given the dreadful Sencha acquisition, this doesn't sound too good for the employees. Hope you'll find good replacement positions.

Congrats to the founders, that I met during a conference, super developers.

Thanks for the contribute to the open source projects!

Can anybody help point/predict numbers involved in acquisition ?

As a Sencha user that has gone through Idera acquiring a product I use, don't count on any product development or meaningful support coming out of them

Their model seems to be farming out choosing canned replies to the cheapest labor they can find. Things that break will stay broken, no one they keep employed will actually know how anything works, let alone how to maintain it.

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

For people coming to this thread looking for alternatives: I'm quite happy with Scrutinizer [1], especially for the easy setup and automatic code quality analysis.

1. https://scrutinizer-ci.com/

Glad to hear that. Travis is also being used in my company and every build spawns a new virtual machine which takes almost a year to boot up. I heard good things about CircleCI. will give it a try asap.

There’s no market for standalone CI/CD. Everything is converging around automation, cloud platforms and version control hosting.

To all of these types of acquisitions, my initial thoughts are always "At least it wasn't oracle"

Congratulations on the acquisition!

The main problem with Travis was that is stayed with the CI part (as the name suggests) while people wanted a CI/CD solution that helps with deployments and monitoring as well.

F.D. I work for Codefresh a full CI/CD solution (competitor to TravisCI)

Could be better, could have been worse.

When will name change to "Travisa Continuo" be announced?

Reply on news.ycombinator.com