Ask HN: Is the CI space overcrowded?
1. Do you think it's overcrowded? Is there space for new companies or is CI basically a "solved problem"? If not what do you dislike with current offerings?
2. Do you prefer a third party CI as compared to the hosting provider offering their own CI at a lower price? Assuming here that the hosting provider would offer lower price because their main income is from the 24/7 hosting fees. Or would you simply switch to the hosting providers CI if it was good?
Disclosure: I am the founder Sourcevoid, a cloud/PaaS company. I'm a little split on how much CI functionality we should integrate into our platform, compared to just trying to promote third party CI providers instead. We already do a fair amount via our build system, but at the same time CI is more than just the build process of course. This question is not about our company or our offerings, I just think it's an interesting question to discuss.
20 comments
[ 3.0 ms ] story [ 57.4 ms ] threadWe picked our CI solution because it was the only cloud offering we could find that supported Bitbucket and also allowed us to set up our own fully-custom environments to run against - without Docker.
Sadly, it took about a week's worth of research to figure that out. And I'm a bit concerned that in this crowded market they'll go out of business and leave us high and dry.
We migrated there from Bamboo Cloud when Atlassian discontinued it. It's nearly a direct drop-in replacement, and they even had docs specifically about Bamboo migrations. Their customer support during onboarding was also superb, and they've been responsive to feature requests. We've been using it for almost a year now, and overall we're pretty pleased.
What are you using currently?
I would, ideally, like a hosted build server, and a hosted Octopus - I really like it. Not the biggest fan of team city, but it works, and it's the only thing I know well.
We've had a couple occasions where we ran out of disk space (though not since we increased the disk size and added a cleanup job), and a few times a build agent has randomly stopped responding and needed to be restarted, but nothing we couldn't easily diagnose and fix.
Amy: “Saturation” is a load of bullshit :)
Nathan: Really it just shows the market exists.
Amy: It’s more than that. So much more than that. If a million people use Harvest, there’s no way they’re all served well by the same tool. The presence of other products doesn’t just show opportunity, it CREATES opportunity. Because wherever there’s a big biz, there will be lots of dissatisfied customers.
Source: https://stackingthebricks.com/difficulties-for-nathan-barrys...
For CI, it's either: "too GUI" or "not enough programmable".
Also, CI is an area that absolutely cries out for container technology, but the state of containers on Linux[1] is absolutely abysmal. Maybe it'll be better in ~5 years when we'll hopefully be about 40% towards the capabilities with Solaris Zones. (Here's a hint: If you cannot fully 'contain' root and users/mounts/devices, then you're not being serious.)
[1] The most popular platform for this, by a far margin.
How would the sweet-spot look like?
(However, from the documentation I got the impression that the new 2.x Jenkins bits were quite repository-centric. It turns out that what I want is really to define the whole CI infrastructure separately from my repos with a few rules to generate appropriate jobs, etc. Perhaps the solution to that is to just define a repo for all-the-builds? Still need to look into it.)
We have decided to go different route, even though it is kinda held together by duct-tape :)
1. We have several shell-scripts that use the $JENKINS_URL/script to update global configuration. A.f.a.i.k. the /script endpoint gives you access to almost all of the jenkins internals to be operated with groovy. So thats how we set-up i.e. plugins, slave-providers, secrets, shared config-files, e.t.c
2. for job definitions, we use jenkins-job-builder [1] with the pipeline plugin [2] We then store both the job-builder configs and the jenkins-files they point to in a single repo, achieving the "define a repo for all-the-builds" solution.
3. to reduce repetition we used shared pipeline library, where we put all of (groovy) functions to be shared across jobs.
Neither shell-scripts for /script endpoint or the job-builder configs are particularly nice, but they get the job done. But we used them even before jenkins-files/pipelines/2.x
The 2.x bits do help quite a lot :-)
[1] https://docs.openstack.org/infra/jenkins-job-builder/ [2] https://github.com/rusty-dev/jenkins-job-builder-pipeline
This means that everything needs to be serializable, and that in reality you are not really executing groovy statements, but rather passing continuations.
This is a reason why you have @NonCPS annotiation, that allows you to opt-out of that behavior.
Why hasn't anyone developed a CI-orcherstration library yet? Is it actually a difficult problem?
Remember, I need this thing to be invoked by Gerrit, periodically, whenever there's a push (well, polling would be fine on this one), etc.
It turns out this is pretty complicated... and maybe nobody does it just right for you. (Hence my other comment. I want ultimate programability. As long as you give me visualization, then I'm OK. I can deal with having to edit a file and pushing rather than doing it through a GUI.)
I think it's interesting to consider what hacker-oriented tools might look like. GitHub close to launch might qualify: simple interface, a model where (at least conceptually) projects are owned by individuals not organisations, and a simple but pretty pleasant-to-use issue tracker with no "workflow" type mechanisms. A lot of this has changed now (support for mandating code reviews!) and from a revenue point of view I'm not sure they're wrong to do these things. But it was the simple, hacker-friendly version that got them their initial mindshare.
I'm not entirely sure what the GitHub 1.0 of CI would look like, but probably not like the current offerings.
The trick with CI, like task/project management software, is that people don't look at what works. They don't try and compete on intrinsics like stablility, extensibility, etc, and really after 12 months on any platform, any mid-large size company is going to care more about those things than new shiny.
Jenkins had the absolute worst UI for a long time, and it still was many people's top choice for CI. You're generally writing a tool for programmers, after all.