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.
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!
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
For one of my projects, I have TravisCI building release binaries for Windows, Linux, and macOS.
Of course that doesn't explain why open source projects would switch, but it could just be a mind share thing.
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...
I hear Appveyor and Azure Pipelines are the two most usable Windows build systems; I'm quite happy on Appveyor.
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.
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...
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.
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).
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.
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.
This is another homepage that already assumes that everyone knows what it does and is no help to people unfamiliar with it.
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.
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.
(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!
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...
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.
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.
https://www.ideracorp.com/brands
and
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.
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.
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.
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.
Thanks for the contribute to the open source projects!
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.
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).
F.D. I work for Codefresh a full CI/CD solution (competitor to TravisCI)
