Travis CI Is Laying Off Senior Engineer Staff(twitter.com)
twitter.com
Travis CI Is Laying Off Senior Engineer Staff
https://twitter.com/alicegoldfuss/status/1098604563664420865
104 comments
Always used Circle in my Rails app, works very nicely (even though the web experience has been going downhill a little bit lately).
Agree 100%. Free CI really did provide a massive boost to collaborative open source projects.
As a user, it did a lot to increase software quality: not just catching inadvertent bugs, but also ensuring that there was at least some reproducible way to get the code working, that didn't depend on some implicit configuration of the authors system.
As a maintainer, accepting simple pull requests becomes much easier when you can quickly look over the code and check the CI status, and not have to try it out locally yourself. It was certainly critical to the "social coding" idea behind GitHub.
So thanks to the team that put it together. Even if the product you built doesn't live on in the way you hoped, it has certainly had a lasting impact for the better on the open source world.
As a user, it did a lot to increase software quality: not just catching inadvertent bugs, but also ensuring that there was at least some reproducible way to get the code working, that didn't depend on some implicit configuration of the authors system.
As a maintainer, accepting simple pull requests becomes much easier when you can quickly look over the code and check the CI status, and not have to try it out locally yourself. It was certainly critical to the "social coding" idea behind GitHub.
So thanks to the team that put it together. Even if the product you built doesn't live on in the way you hoped, it has certainly had a lasting impact for the better on the open source world.
Previous discussion of the acquisition on HN, complete with a prediction of just this happening can be found at https://news.ycombinator.com/item?id=18978251
I called it. The money men have praises Idera for their new and innovative approach to software development. Also know has fixed cost devlopement to the lowest bider.
If you want stop this type of practice please don't sign multi year contracts. That is stage two. This is where they get their value.
Without the contracts they can't use it as leverage to take out huge debts -- where they get their value from.
If the fed raised the rates this practice would also end.
If you want stop this type of practice please don't sign multi year contracts. That is stage two. This is where they get their value.
Without the contracts they can't use it as leverage to take out huge debts -- where they get their value from.
If the fed raised the rates this practice would also end.
There's a lot of problems to go around.
If you're a founder, you're usually going to cash out for the right price. Everyone has their price. No one wants to grind forever. This isn't a problem if you're profitable enough that you can hold forever (Basecamp).
If you're an investor, you're struggling for returns right now (to your point about interest rates and the Fed). You're going to squeeze whatever you can get your hands on as hard as possible (as an investor myself in real estate and small SaaS companies I've bought, I try very hard to not do this, but you're hedging against a multiple you paid for the asset; you don't want the asset's cashflow to disappear and watch your capital evaporate).
Interest rates rising would help, but so would orgs more tilted towards employee ownership. You have to align incentives. Are you happy with a lifestyle business? (Not derogatory! I'd take a lifestyle business any day over any sort of possible unicorn status) Are your coworkers/shareholders? Would you customers be willing to be shareholders thereby becoming stakeholders? These problems are solvable with corporate structures and governance.
Such a shame to see this happen. Great opportunity for GitLab and their CICD team though.
If you're a founder, you're usually going to cash out for the right price. Everyone has their price. No one wants to grind forever. This isn't a problem if you're profitable enough that you can hold forever (Basecamp).
If you're an investor, you're struggling for returns right now (to your point about interest rates and the Fed). You're going to squeeze whatever you can get your hands on as hard as possible (as an investor myself in real estate and small SaaS companies I've bought, I try very hard to not do this, but you're hedging against a multiple you paid for the asset; you don't want the asset's cashflow to disappear and watch your capital evaporate).
Interest rates rising would help, but so would orgs more tilted towards employee ownership. You have to align incentives. Are you happy with a lifestyle business? (Not derogatory! I'd take a lifestyle business any day over any sort of possible unicorn status) Are your coworkers/shareholders? Would you customers be willing to be shareholders thereby becoming stakeholders? These problems are solvable with corporate structures and governance.
Such a shame to see this happen. Great opportunity for GitLab and their CICD team though.
This is not a investment. It is a tool for leverage. The goal is not to grow the company it's to get as many contracts as they can and lower the ebita. Once they do this they will take out huge loans for the next company to destroy.
I don't blame the founders. But at the same time I think if enough of these deals for bad these types of investors will stop their bad practices.
This sort of move not only hurts employees. It hurts those who use the product too. It's a net bad for everybody but a few.
I am still digging into how these things work and how the money gets out. But I would not be surprised if sometime in the future this sort of business engineering would be made illegal.
Look what PE did to solar winds and general dollar. Both had huge piles of cash and were drained and put back on the market for the general public to pay the debt.
I don't blame the founders. But at the same time I think if enough of these deals for bad these types of investors will stop their bad practices.
This sort of move not only hurts employees. It hurts those who use the product too. It's a net bad for everybody but a few.
I am still digging into how these things work and how the money gets out. But I would not be surprised if sometime in the future this sort of business engineering would be made illegal.
Look what PE did to solar winds and general dollar. Both had huge piles of cash and were drained and put back on the market for the general public to pay the debt.
> This is not a investment. It is a tool for leverage. The goal is not to grow the company it's to get as many contracts as they can and lower the ebita. Once they don't his they will take out huge loans for the next company to destroy.
All investments are buying cashflow or value appreciation, that is the end goal, regardless of the method. As long as the PE firm involved gets more cash out then they put in, it was a successful investment.
I address how both companies and customers can protect themselves in my comment you replied to. If someone buys a private company, the majority shareholders were willing participants. Better ownership and stakeholder models protect against these outcomes.
No one is going to buy Let's Encrypt. Consider if that model would work for CICD as a service. Start a non-profit, round up the talent, fire up the infrastructure, provision a Stripe account, and build something better. Let's Encrypt secures the web for $3 million/year. Crunchbase and Glassdoor mention Travis CI had ~$1-1.5 million/year in revenue.
All investments are buying cashflow or value appreciation, that is the end goal, regardless of the method. As long as the PE firm involved gets more cash out then they put in, it was a successful investment.
I address how both companies and customers can protect themselves in my comment you replied to. If someone buys a private company, the majority shareholders were willing participants. Better ownership and stakeholder models protect against these outcomes.
No one is going to buy Let's Encrypt. Consider if that model would work for CICD as a service. Start a non-profit, round up the talent, fire up the infrastructure, provision a Stripe account, and build something better. Let's Encrypt secures the web for $3 million/year. Crunchbase and Glassdoor mention Travis CI had ~$1-1.5 million/year in revenue.
It sounds like a new spin on 1980s-style corporate raiding? Pillaging a company then moving on, leaving behind the carcass. I can't see how this behavior helps us as a society, it's legal but unethical.
I don't know if it's good or bad, but we like to think that vultures fill a niche, make ecosystems richer.
Sure, our economies and ecosystem of firms doesn't necessarily have to look like a full out evolutionary war for resources, but .. it sort of does, and it's not going to change any time soon.
So, im that sense if we want stable and nice companies, we have to care for them. Sort of like we do with pandas, rhinos, and so on.
One possibility is doing pledge, using corporate bylaws to try to guarantee some of that niceness. Do it through IT (and startup, and VC and so) communities' wall of fame/shame.
Sure, our economies and ecosystem of firms doesn't necessarily have to look like a full out evolutionary war for resources, but .. it sort of does, and it's not going to change any time soon.
So, im that sense if we want stable and nice companies, we have to care for them. Sort of like we do with pandas, rhinos, and so on.
One possibility is doing pledge, using corporate bylaws to try to guarantee some of that niceness. Do it through IT (and startup, and VC and so) communities' wall of fame/shame.
The problem is these vultures tend to swoop in while the company is still alive and kicking. Everybody expects their company to do amazing in 3 to 5 years and if does not they kick it to the curb.
The problem is if you look at all the amazing companies that are doing really well. The majority of them took near 10 years to come to their own. Half the amazing companies in SV if ran buy these PE guys would not exist if they were given to them at year 5 of their life.
The problem is if you look at all the amazing companies that are doing really well. The majority of them took near 10 years to come to their own. Half the amazing companies in SV if ran buy these PE guys would not exist if they were given to them at year 5 of their life.
If it was that alive and kicking founders wouldn't have sold it off to the vultures. :/
There's difference between PE and PE. Look at SoftBank's Vision fund, they want to invest still more than 100B USD (it's already at around a 100), they want to fuel growth of sectors, etc. And then there's "company turnaround management", where the employee count chart gets turned around, and cashflow becomes king.
There's difference between PE and PE. Look at SoftBank's Vision fund, they want to invest still more than 100B USD (it's already at around a 100), they want to fuel growth of sectors, etc. And then there's "company turnaround management", where the employee count chart gets turned around, and cashflow becomes king.
What do you do when the idea that made you start a new company 8 years ago, made you get up every morning, doesn't do it for you now, and all of your equity is tied up in your old idea?
I don't think I have that kind of stamina. When you cash out there's no guarantee the next person will do a better job than you did.
I don't think I have that kind of stamina. When you cash out there's no guarantee the next person will do a better job than you did.
I'd like to see a real discussion among the readership of this news site about the kind of companies people want to build. Do you want to create a great place to work and grow that builds value that scales smoothly, or a unicorn that makes VCs, Private Equity, and the douchebag CEO you hired from Cisco rich and you without a job? If the answer is b, that is fine, but technical founders and employees should have their minds and eyes open about how it works.
> The money men have praises Idera for their new and innovative approach to software development.
Buying something that's already been developed and then not developing it further is a 'new and innovative approach to software development'?
Buying something that's already been developed and then not developing it further is a 'new and innovative approach to software development'?
You joke, but when have you ever heard of a software company calling their product complete, firing most of their developers, and moving to maintenance mode? Building a product and making money by selling it is somewhat of a novelty in the hypergrowth VC world of software.
As a developer this obviously sucks but this seems to be pretty efficient from a high level view. If all the low hanging fruit is done and all future development is just adding features with continually diminishing returns, it makes sense to just go into maintenance mode, extract your profits, and let your developers go work on something else
And, then, after years have passed and the hardware it's running on starts failing, developers have to scramble to update components to a version that's actually supported.
Maintenance. Real maintenance is cheap.
New SDK comes out, make it compile, do the necessary refactor. That's it. Minimal team, no real deadlines, just pure throughput.
New SDK comes out, make it compile, do the necessary refactor. That's it. Minimal team, no real deadlines, just pure throughput.
By that time the money is already made from those for who it's cheaper to stay than moving away ... so you can buy the next company with a dying product, milk their customers and move on.
I bet we could find tons of other private equity examples. It's how they do. When they aren't firing most staff to then try to re-sell the company instead.
I agree about calling a product complete. MS Office and Windows were probably pretty complete in the early 2000s. But instead of firing the devs it would be nice if they put them to work on something new.
That's the joke
That's what they've done for the Aurea/Update CRM and they are trying to do it with Qlik. Sencha is a great example of where they buy a company, fire devs, and then hope and pray they can continue with the same revenue due to client inertia.
Is Idera basically the Valeant pharma of software?
Also relevant - https://old.reddit.com/r/devops/comments/at3oyq/it_looks_lik...
"Yep. We were terminated by Idera without even our managers knowing."
in wake of travis being acquired last month. https://blog.travis-ci.com/2019-01-23-travis-ci-joins-idera-...
"Yep. We were terminated by Idera without even our managers knowing."
in wake of travis being acquired last month. https://blog.travis-ci.com/2019-01-23-travis-ci-joins-idera-...
> "Yep. We were terminated by Idera without even our managers knowing."
Not sure if thats douchebaggy. I've seen several layoffs like this, where everyone finds out at the same time not by levels.
Not sure if thats douchebaggy. I've seen several layoffs like this, where everyone finds out at the same time not by levels.
You having seen it doesn't mean it isn't awful. Never mistake "common", or even "not rare", with "good"
It also doesn't sound like everyone found out at the same time.
It also doesn't sound like everyone found out at the same time.
[deleted]
In the blog about the private equity acquisition, the CTO says "With the support from our new partners, we will be able to invest in expanding and improving our core product"
I wonder if he believed that, even as he wrote it?
I wonder if he believed that, even as he wrote it?
My cynical side and bad experiences have taught me if the new guys are saying it it might be true. If the old owner is saying it, it might as well be a lie because they can't back it up even if they think they're being honest.
When the new owners figure out what they actually want to do it's easy enough to get rid of the messenger. Either fire them or they leave in a huff.
When the new owners figure out what they actually want to do it's easy enough to get rid of the messenger. Either fire them or they leave in a huff.
It's complete BS, but for some reason C* people often don't understand how dumb this is, but for them it might mean a big payday so they don't care. The inherent knowledge walks out the door with the engineers, and all that is left is code and no knowledge. Hire cheap devs and before you realize it it becomes a write-off for the acquirer. Everyone wins except the people who worked hard to build it in the first place.
> all that is left is code and no knowledge
The irony is that the better the engineering staff was, the better this works out for the firing company.
If some newbies can pick up the code and quickly become productive, that's to the credit to the staff that was fired.
The irony is that the better the engineering staff was, the better this works out for the firing company.
If some newbies can pick up the code and quickly become productive, that's to the credit to the staff that was fired.
From the tweet [0] it seems there is going to be a huge tech debt. I don't know how Idera is planning to expand upon the acquisition after letting go people like this.
> Some know the skinny on dozens of different open source projects and ecosystems, others understand run time and dep mgmt for like 17 languages and even more tooling, and automated image mastering to handle it all. > Others are rewriting what it means to manage communities in this era. They had to garden github issue repos with 1000s of tickets and find the patterns, and know a wide swath of the open source community in ways most people will never get to again
[0] https://mobile.twitter.com/carmatrocity/status/1098538650525...
> Some know the skinny on dozens of different open source projects and ecosystems, others understand run time and dep mgmt for like 17 languages and even more tooling, and automated image mastering to handle it all. > Others are rewriting what it means to manage communities in this era. They had to garden github issue repos with 1000s of tickets and find the patterns, and know a wide swath of the open source community in ways most people will never get to again
[0] https://mobile.twitter.com/carmatrocity/status/1098538650525...
To (sadly) be fair, Travis has already been struggling mightily with tech debt the last few years. There have been a lot of issues surface and re-surface that sure seem like they shouldn't be a big deal.
For example, setting a build to use ruby 2.4 is supposed to run the latest ruby 2.4.x, but would frequently build against ancient, unsupported rubies for a while, before being silently fixed.
For example, setting a build to use ruby 2.4 is supposed to run the latest ruby 2.4.x, but would frequently build against ancient, unsupported rubies for a while, before being silently fixed.
They've also been very slow to ship updated machine images— Ubuntu 14.04 wasn't available until late 2015, and 16.04 wasn't until Nov 2018:
https://blog.travis-ci.com/2015-10-14-opening-up-ubuntu-trus...
https://blog.travis-ci.com/2018-11-08-xenial-release
The extremely long lag combined with some communications from Travis developers on related Github issues strongly implied that shipping these was a highly manual process, not just a matter of updating a few Packer configs and calling it a day. I'm not arguing that it's trivial, but it should have been a week or two of effort at most.
Now, lots of their userbase could be covered by using docker environments, or by the natural isolation supplied by the language platform (virtualenv, rbenv, etc), but at the end of the day, it's frustrating if your CI environment is drifting away from what developers are actually using themselves.
https://blog.travis-ci.com/2015-10-14-opening-up-ubuntu-trus...
https://blog.travis-ci.com/2018-11-08-xenial-release
The extremely long lag combined with some communications from Travis developers on related Github issues strongly implied that shipping these was a highly manual process, not just a matter of updating a few Packer configs and calling it a day. I'm not arguing that it's trivial, but it should have been a week or two of effort at most.
Now, lots of their userbase could be covered by using docker environments, or by the natural isolation supplied by the language platform (virtualenv, rbenv, etc), but at the end of the day, it's frustrating if your CI environment is drifting away from what developers are actually using themselves.
This was concerning for several years now. Who knows when 18.04 will make an appearance. 2021? Never?
I appreciate what they were trying to do with their multiple versions of every language in their stock images. But, in practice there were numerous compatibility problems. If you look at the C++ tickets, you can see how utterly unusable their offering was for this language. From the outside, it looks like they painted themselves into a corner and are mired in technical debt. Quite why it took two and half years to support 16.04 is a question I'd be very interested to know more about.
One solution is to use custom docker images. But that negates any advantages Travis might have had. I can run a docker image anywhere. So when I switched over to GitLab, I use GitLab CI with docker images and custom runners to do fairly comprehensive platform coverage. Something Travis will never do.
They also made a questionable business decision in tying themselves to GitHub. Why no integrations with BitBucket, GitLab, Jenkins, and all the other hosting and automation solutions out there? I had to write Travis off purely because of its lack of availability. The above problems were also an issue, but if it doesn't integrate with your hosting solution, it's a non-starter.
I appreciate what they were trying to do with their multiple versions of every language in their stock images. But, in practice there were numerous compatibility problems. If you look at the C++ tickets, you can see how utterly unusable their offering was for this language. From the outside, it looks like they painted themselves into a corner and are mired in technical debt. Quite why it took two and half years to support 16.04 is a question I'd be very interested to know more about.
One solution is to use custom docker images. But that negates any advantages Travis might have had. I can run a docker image anywhere. So when I switched over to GitLab, I use GitLab CI with docker images and custom runners to do fairly comprehensive platform coverage. Something Travis will never do.
They also made a questionable business decision in tying themselves to GitHub. Why no integrations with BitBucket, GitLab, Jenkins, and all the other hosting and automation solutions out there? I had to write Travis off purely because of its lack of availability. The above problems were also an issue, but if it doesn't integrate with your hosting solution, it's a non-starter.
On top of how late "new stuff" often was, I never understood why they kept out of date, unsupported stuff running for so long - especially for free, open source projects.
http://rubies.travis-ci.org/ They support ruby 1.8.7 and ree. ree went unsupported in 2013 (https://www.infoq.com/news/2012/02/ruby-eee-eol)
If anything, I feel like they are actually doing the open source community a disservice by supporting build environments that are no longer supported by the upstream community. They legitimize testing against ancient, unsupported environments, rather than moving forward deliberately to stay on a supported stack.
I understand there is a burden on updating software, but given all the trouble we have with breaches in old software, we need to bias the world toward staying on stacks that get security updates rather than sitting stagnant.
http://rubies.travis-ci.org/ They support ruby 1.8.7 and ree. ree went unsupported in 2013 (https://www.infoq.com/news/2012/02/ruby-eee-eol)
If anything, I feel like they are actually doing the open source community a disservice by supporting build environments that are no longer supported by the upstream community. They legitimize testing against ancient, unsupported environments, rather than moving forward deliberately to stay on a supported stack.
I understand there is a burden on updating software, but given all the trouble we have with breaches in old software, we need to bias the world toward staying on stacks that get security updates rather than sitting stagnant.
I still don’t know how to test against py3.7...
From the previous discussion, it seems like Idera's mode of operation is stopping active development on the product, and maintaining it more or less as-is as long as there are people using it. Then it's not necessary to reduce tech debt.
This same pattern happens with 'dying' ERP software. The users aren't going anywwhere, unless you for ce them.
It takes years and millions of dollars to switch ERP platoforms.
Buy the company for...what a year or two (or even less) worth of contracts equals.
Fire all the developers. Keep a skeleton support staff. Fire sales/marketing. In-house everything else. Then just keep getting paid by customners until they all finally go away.
It takes years and millions of dollars to switch ERP platoforms.
Buy the company for...what a year or two (or even less) worth of contracts equals.
Fire all the developers. Keep a skeleton support staff. Fire sales/marketing. In-house everything else. Then just keep getting paid by customners until they all finally go away.
You forgot the last step. Once you finally collapse, sell all source code and licenses to use the software to the last remaining customers.
Swapping out Travis for something else takes a few minutes. If you have a lot of repositories and very complicated scripts, it might take a day or so. But ultimately, the lock-in for CI solutions is minimal. The effort to migrate is very small.
Over the last few years, I've transitioned projects between Jenkins, Travis, AppVeyor, CircleCI, GitLab and others. In most cases, the logic had mostly been factored out in to shell scripts and batch files. Telling one CI system to set up the build/test environment and run that script is pretty much the same as any other.
And this might be the reason why this layoff has happened. What future did Travis have as a business? What was its growth potential? How many paying customers did it have? When everything you offer is done better, often for free, by your competitors and customers can easily set up their own self-hosted replacement if they choose, I'm a bit skeptical that the business was worth that much in the first place.
Over the last few years, I've transitioned projects between Jenkins, Travis, AppVeyor, CircleCI, GitLab and others. In most cases, the logic had mostly been factored out in to shell scripts and batch files. Telling one CI system to set up the build/test environment and run that script is pretty much the same as any other.
And this might be the reason why this layoff has happened. What future did Travis have as a business? What was its growth potential? How many paying customers did it have? When everything you offer is done better, often for free, by your competitors and customers can easily set up their own self-hosted replacement if they choose, I'm a bit skeptical that the business was worth that much in the first place.
But Travis is the choice of well weapon DevOps people, they will be able to swap out to a new CI in 10 seconds flat. Hell, a dingbat like me could probably do it in a day. An ERP system, not so much.
Depends on the complexity of your CI. Big projects might take days to migrate, or even more.
Last company I was at, our ERP transition took years
> I don't know how Idera is planning to expand upon the acquisition...
I would guess they are not, which is consistent with how they seem to have treated past acquisitions.
I am not sure if a developer-focused integration-dependent tool like CI can continue to consistently bring in a revenue stream without getting much development attention... but I think they're going to find out.
I would guess they are not, which is consistent with how they seem to have treated past acquisitions.
I am not sure if a developer-focused integration-dependent tool like CI can continue to consistently bring in a revenue stream without getting much development attention... but I think they're going to find out.
I hope no one minds a quick plug... sourcehut has a build service with a comparible UX to Travis CI, but more powerful in some respects. https://sourcehut.org Get in touch if you want some tips on moving from Travis to builds.sr.ht.
I wish I could hire some of the recently unemployed, but I just don't have the budget. If you want me to circulate your resumes in Philly, feel free to email them to me. Best of luck.
I wish I could hire some of the recently unemployed, but I just don't have the budget. If you want me to circulate your resumes in Philly, feel free to email them to me. Best of luck.
"comparable UX to travis" is enticing to me, as I am fond of travis.
Where do I find pricing information? (Was hoping for the standard "Pricing" link).
Does it require a repo hosted on sourehut too, or can the CI be used independently?
Where do I find pricing information? (Was hoping for the standard "Pricing" link).
Does it require a repo hosted on sourehut too, or can the CI be used independently?
There's an open todo ticket to add a public pricing breakdown - right now you only see it after signup. This is what the page looks like:
https://sr.ht/lS5M.png
I'll see if I can't get public pricing info up later today.
>Does it require a repo hosted on sourehut too, or can the CI be used independently?
You can use the CI independently. Right now there's a GitHub integration and I'm open to adding more :)
https://sr.ht/lS5M.png
I'll see if I can't get public pricing info up later today.
>Does it require a repo hosted on sourehut too, or can the CI be used independently?
You can use the CI independently. Right now there's a GitHub integration and I'm open to adding more :)
Update: pricing page is now shown here:
https://sourcehut.org/pricing/
https://sourcehut.org/pricing/
It's not clear from that page what I'm getting for my money.
You generally wouldn't go directly here. You'd start at the link I originally posted:
https://sourcehut.org/
Or did you feel that this isn't helpful either?
https://sourcehut.org/
Or did you feel that this isn't helpful either?
Hi, sorry - I'm looking for more along the lines of "how much X I get for Y" - e.g. to do a few ARM kernel builds a month, what would it cost me?
It's not ala-carte. You pay your subscription fee and get unlimited access to all features. If you start to use more resources than is reasonable, I'll shoot you an email and talk about it. It doesn't sound like you would, though.
This is a bait-and-switch for most of us who are used to free Travis service, as your offering is not free.
Well, during the alpha it's free, but you're right that it will eventually require payment. But the incentives are better this way anyway: if it were free then in a few years we could very well be having this conversation in the wake of layoffs at sourcehut following an aquisition. Sourcehut isn't based on the VC grow-until-you-burst model. If you pay for your account, you can be confident it's sustainable and aligned with your interests.
Also, if anyone has trouble affording an account, please send me an email. I don't want anyone to be left out because they can't afford the subscription fee, we'll sort something out.
Also, if anyone has trouble affording an account, please send me an email. I don't want anyone to be left out because they can't afford the subscription fee, we'll sort something out.
He's not obligated to provide a free service. He's trying to run a business here.
Honestly I'm astonished at the speed with which this happened, given the recency of their acquisition. Seems amazingly cynical of their new parent company.
PE firms are there for profit. To make profit you cut costs or raise revenue. Guess which is faster?
I worked at a company that was completely turned around by PE. Improved culture, employee happiness, expanded business, etc.
They were in it for the flip sure, but there are different models for achieving this. It's not always a chop shop job.
They were in it for the flip sure, but there are different models for achieving this. It's not always a chop shop job.
There was a time when I wanted to use Travis CI but the pricing was too much. Then, CircleCI came along with a free plan, and when the time came to upgrade, we did it so easily since we’re already invested in the platform.
I wish Travis CI they did this from the start since I like their platform and had some open source projects there and again could have easily upgraded. This is where the fremium model would have worked.
I wish Travis CI they did this from the start since I like their platform and had some open source projects there and again could have easily upgraded. This is where the fremium model would have worked.
Huh? Travis has had a free level for a while (I've been using it for my libraries on github).
Only for open source repo's. For those who have to choose a CI for business use that may not be usable.
In what sane business is 50$ a month over a free tier the deciding factor in choosing a CI system?
In quite many I have encountered as an employee.
When the offering itself is practically identical.
Most (?) developers can't even buy a mouse without prior permission.
"Free" is more convient at work than at home. If I need something at home I just pay. At work ...
Compare the hazzle of getting a Win10 VM up and running compared to a Ubuntu one with licensing issues. A Win10 image is like 3 days away. An Ubuntu 30 min. The slower alternative also happens to cost money.
"Free" is more convient at work than at home. If I need something at home I just pay. At work ...
Compare the hazzle of getting a Win10 VM up and running compared to a Ubuntu one with licensing issues. A Win10 image is like 3 days away. An Ubuntu 30 min. The slower alternative also happens to cost money.
And making it free, at least initially, for businesses removes the requirement of having to have a conversation about it or get permission. It's the same way Dropbox gained so much traction (arguably, the first to execute this model).
You let all of the employees use something for free, come to rely on it, and then all of a sudden it's become entrenched in the workflow/culture/whatever. At that point, it's easier to just pay for the service than to switch.
See Slack.
You let all of the employees use something for free, come to rely on it, and then all of a sudden it's become entrenched in the workflow/culture/whatever. At that point, it's easier to just pay for the service than to switch.
See Slack.
I've worked at companies of all sizes, and at every one of those jobs, I've had some form of MSDN access.
I've never ran into the issues you're referring to. Microsoft makes it both easy and cheap to obtain development licenses for their software.
I've never ran into the issues you're referring to. Microsoft makes it both easy and cheap to obtain development licenses for their software.
CircleCI is also a superior product, especially CircleCI 2.0. Their Docker integration is top notch, and there are lots of ways to optimize build performance.
Sorry to the Travis engineers, in case you don‘t have any other plans already, at JustWatch, we‘re hiring just around the corner :)
I've been using travis Enterprise for over two years and what has kept that going has been the amazing support and development team at Travis who have always helped us during an emergency, been very responsive and informative in all our interactions. They are the reasons I have backlogged the project to migrate.
Keys issues i've seen in our Enterprise install... * Upgrades can go bad, very quickly and very silently. * Build images are out-dated, missing security patches, bloated, and not easily provisioned with custom features to integrate our tools with theirs. * no tooling for docker builds/deployments * long start up time on the build images. * Enterprise documentation (though it's been improved a lot recently)
Best of luck to #travisAlums, I hope you get picked up quickly.
Keys issues i've seen in our Enterprise install... * Upgrades can go bad, very quickly and very silently. * Build images are out-dated, missing security patches, bloated, and not easily provisioned with custom features to integrate our tools with theirs. * no tooling for docker builds/deployments * long start up time on the build images. * Enterprise documentation (though it's been improved a lot recently)
Best of luck to #travisAlums, I hope you get picked up quickly.
We’re on a custom plan and pay them quite a bit every month. However after their acquisition, their support is basically non-existent in responses.
We’re migrating to in-house Jenkins now. Can’t trust third parties to handle critical infra.
I was a big pusher for Travis, but they’ve lost my trust.
I would advice everyone else to migrate off and mitigate their risk.
We’re migrating to in-house Jenkins now. Can’t trust third parties to handle critical infra.
I was a big pusher for Travis, but they’ve lost my trust.
I would advice everyone else to migrate off and mitigate their risk.
Whelp, I might be looking at CircleCI vs TravisCI again.
You should have already been doing this, before the acquisition. It felt like Travis had been on auto-pilot for a long time. It was painfully obvious to me and our team that Circle is actually hungry and constantly innovating and wanted our business. We moved one project to Circle, waited a bit, and then moved everything away from Travis. Don't regret it one bit.
I got stuck as soon as I found out CircleCI didn't scrub secrets from the log automatically like TravisCI. I know, I know, but we have a pretty hefty legacy OSS build in place and that's a lot to shore up before go time haha. Need to check back on that feature request...
Hard to want to keep updating your working CI solution for your open source stuff while holding down a job and life and everything else. :)
I kept putting of switching from Travis to Circle-CI in one of my open source projects, But when I did get around to it the whole thing went pretty smoothly and easily and I regret not doing it earlier.
1.The builds are much faster now. 2. The configuration has virtually no hacks anymore as I'm using Circle-CI own docker images (including browsers). 3. And the UI/UX is superior as well.
1.The builds are much faster now. 2. The configuration has virtually no hacks anymore as I'm using Circle-CI own docker images (including browsers). 3. And the UI/UX is superior as well.
Hah agreed :) We had one project that kept breaking in Travis, and we started to realize that starting over in Circle was easier than the troubleshooting / feedback loop in Travis.
There is also Drone for self-hosted: https://drone.io
I would recommend considering GitLab CI as well. I started moving some projects over there a few months back and I've been quite happy with it. The transition from Travis CI was pretty smooth. There are some differences in concepts (cache vs artifacts), but the GitLab CI documentation is pretty good.
Plus you can run it all locally with a couple of docker containers (gitlab-ce/gitlab-ee & gitlab-runner).
Plus you can run it all locally with a couple of docker containers (gitlab-ce/gitlab-ee & gitlab-runner).
I've worked somewhere where it was taking so much effort getting Jenkins set up. In the long run it would be better, but I couldn't wait months and months for the stuff that I got working in maybe 20 minutes with a .travis.yml file.
Disappointing to see this happen. I like devops stuff that covers 80% of your need with 20% of the work.
Disappointing to see this happen. I like devops stuff that covers 80% of your need with 20% of the work.
More background on Idera: https://medium.com/@dirk.avery/r-i-p-travis-ci-347753c73775
I’ve reluctantly used Travis for the last years and hardly seen new features or long standing open bugs being fixed.
Not sure what the people were doing but this seems typical for a Ruby project.
Not sure what the people were doing but this seems typical for a Ruby project.
[deleted]
Has anyone got a link to a decent migration guide from Travis to circleci? And I’d Circle don’t have one they’re leaving lots of money on the table.
https://circleci.com/docs/2.0/migrating-from-travis/ has a basic migration guide, but doesn't discuss services like databases or caches.
maccio92(3)
This is kind of how private equity works.
It is sad, I had really liked travis as a product, I don't expect I will be able to continue to.
Travis is just _so easy_ to set up for my basic ruby gem and Rails app projects (I don't want to spend time on setting up CI, I just want it to be done), as well as free for open source -- none of it's competitors have seemed to give me that when I looked before.
Travis, by offering an absolutely brain-dead setup, and giving it away free to open source, really created a revolution in actually doing CI for open source, at least in ruby. Everyone's doing CI now, when few open source projects were before in ruby. That anyone offers free CI for open source at all is probably due to the need to compete with travis. I wonder if it'll stick around.