3 ms·

I think the key is that nobody "wants" to spend any time at all on CI or their build system. It is one of those necessary evils that you have to do to have func

by aftbit 3y ago

I think the key is that nobody "wants" to spend any time at all on CI or their build system. It is one of those necessary evils that you have to do to have functioning software. Once you do it, even if it's a slow buggy pile of hacks, you will just ignore it until the pain gets very very bad. This was the same problem that caused our team to abandon CircleCI. They kept wanting us to rewrite our CI configs, touting various benefits that we just didn't care about. All we wanted was for our janky broken builds to keep working 90% of the time, like they did before Circle tried migrating this or that.

wpietri 3y ago
Some people do want to spend time on that! It depends whether you see fast feedback as a competitive advantage. I once worked on a system where we had excellent test coverage and all our unit tests ran in under a minute. We worked hard to keep it that way, because it was a huge boon to productivity, especially when improving design issues. It also enabled frequent commits and merges, which made collaboration easier. It was a great experience. But yes, from the business perspective, the leading edge is a pretty small audience. (Circa 15%, per Moore.) And the bottom half of the audience by competence, which Moore called the Late Majority and the Laggards, can be well more than half your revenue in a SaaS context because they will create problems for themselves (like slow/buggy builds) that mean higher per-user revenue. And they may also have special feature needs where they'll pay more rather than clean up their messes. In that context, doing the right thing for your business can be very different than doing the right thing for users. Sort of like a physical therapist who makes most of their money from renting crutches and in-home meal delivery, and so doesn't push people to actually get better.
aeyes 3y ago
What did they make you change? I have been using CircleCI since the beginning and the only breaking change I saw was when they introduced workflows. This didn't need any changes to the difficult parts of my own code and was mostly copy-paste. I believe that my configs are fairly complex using almost all existing features across many different projects and build targets.
- aftbit 3y ago
  We started using CircleCI in early 2016, I believe. There have been two major migration points. The first time was when they went from circle.yml to .circleci/config.yml, around 2018, which might have corresponded with Workflows. The second time was when they got rid of their old converged docker containers and moved to custom container runtimes (and a new set of images, none of which did _quite_ the same thing as their old images). Neither of these took tons of effort to resolve, but both broke our builds and made us spend time thinking about CI when we would rather have been iterating on our products. When their later migration happened, Github Actions was just coming around, so we figured that if we had to rebuild and re-test all of our CI, we might as well move it to a more reliable and cheaper runner. Now we only use CircleCI on a handful of legacy repos.
notatoad 3y ago
>I think the key is that nobody "wants" to spend any time at all on CI or their build system. or if they do, they're hosting their own. if you're selling a hosted CI platform, your sales pitch is "pay us $$ instead of paying your staff $$$ to do devops". if your pitch is "pay us $$ and then also spend $$$ on staff hours to manage our service", it's very unlikely the CI is doing anything useful enough that the staff couldn't just run their own thing in-house. it doesn't take much configuration to be more difficult than an EC2 instance running a script on a webhook from your version control.
larusso 3y ago
I had a talk with a circle CI rep at a conference and I tried to explain to him that yes I’m not happy with our custom Jenkins setup (agents, CasC, pipeline library), but that I also want to spend time and money on a migration project to end up at the status co again. If I would go to my boss and say we can either spend some time and fix our setup or spend time plus running costs for this external solution then the answer will be clear. I think convincing teams with huge stacks of CI setup to just switch because of marketing promises isn’t working. I would think of using a new setup when I start from scratch. At the moment at least.

by aftbit 3y ago

wpietri 3y ago

Some people do want to spend time on that! It depends whether you see fast feedback as a competitive advantage. I once worked on a system where we had excellent test coverage and all our unit tests ran in under a minute. We worked hard to keep it that way, because it was a huge boon to productivity, especially when improving design issues. It also enabled frequent commits and merges, which made collaboration easier. It was a great experience. But yes, from the business perspective, the leading edge is a pretty small audience. (Circa 15%, per Moore.) And the bottom half of the audience by competence, which Moore called the Late Majority and the Laggards, can be well more than half your revenue in a SaaS context because they will create problems for themselves (like slow/buggy builds) that mean higher per-user revenue. And they may also have special feature needs where they'll pay more rather than clean up their messes. In that context, doing the right thing for your business can be very different than doing the right thing for users. Sort of like a physical therapist who makes most of their money from renting crutches and in-home meal delivery, and so doesn't push people to actually get better.

aeyes 3y ago

What did they make you change? I have been using CircleCI since the beginning and the only breaking change I saw was when they introduced workflows. This didn't need any changes to the difficult parts of my own code and was mostly copy-paste. I believe that my configs are fairly complex using almost all existing features across many different projects and build targets.

aftbit 3y ago
We started using CircleCI in early 2016, I believe. There have been two major migration points. The first time was when they went from circle.yml to .circleci/config.yml, around 2018, which might have corresponded with Workflows. The second time was when they got rid of their old converged docker containers and moved to custom container runtimes (and a new set of images, none of which did _quite_ the same thing as their old images). Neither of these took tons of effort to resolve, but both broke our builds and made us spend time thinking about CI when we would rather have been iterating on our products. When their later migration happened, Github Actions was just coming around, so we figured that if we had to rebuild and re-test all of our CI, we might as well move it to a more reliable and cheaper runner. Now we only use CircleCI on a handful of legacy repos.

notatoad 3y ago

>I think the key is that nobody "wants" to spend any time at all on CI or their build system. or if they do, they're hosting their own. if you're selling a hosted CI platform, your sales pitch is "pay us $$ instead of paying your staff $$$ to do devops". if your pitch is "pay us $$ and then also spend $$$ on staff hours to manage our service", it's very unlikely the CI is doing anything useful enough that the staff couldn't just run their own thing in-house. it doesn't take much configuration to be more difficult than an EC2 instance running a script on a webhook from your version control.

larusso 3y ago

I had a talk with a circle CI rep at a conference and I tried to explain to him that yes I’m not happy with our custom Jenkins setup (agents, CasC, pipeline library), but that I also want to spend time and money on a migration project to end up at the status co again. If I would go to my boss and say we can either spend some time and fix our setup or spend time plus running costs for this external solution then the answer will be clear. I think convincing teams with huge stacks of CI setup to just switch because of marketing promises isn’t working. I would think of using a new setup when I start from scratch. At the moment at least.