[0xbadcafebee]

Very unfortunately, it's the de-facto tool most businesses use. It's free, but you have the option of support, and everyone has used it. There are better free tools, but they're more complicated for the layperson, and usually don't have support, much less the huge ecosystem of plugins.

As a person who earns probably half his living propping up horrible Jenkins installs, I highly recommend that nobody ever use it. But if you're going to work in corporate-world, you probably will have to use it, so you might as well get comfortable with it.

[sp332]

What would you recommend for a shop that has some mature projects they'd like to add a bunch of tests to, to improve speed and confidence in future changes?

[jupp0r]

Use a SaaS solution like CircleCI, Travis, BuildKite, etc. They all have various upsides and downsides but you will save lots of money vs maintaining you own Jenkins and dealing with all its flaws.

Also, people who are not used to the whole test driven development culture will have an easier time adapting if infrastructure doesn’t constantly break.

[peterwwillis]

Yes, 100%, SaaS is the way to go - unless it is impossible. There are some orgs & projects out there that literally cannot use a SaaS, which usually leads to self-hosting. ("Cost" is not a valid reason, btw - if one more junior manager tells me "oh but it's so much cheaper to self-host" i'm going to take away their lunch money because isn't growing your own lettuce cheaper than paying for it on a sandwich?).

I would say the simplest thing would be to buy a self-hosted GitHub Enterprise, although the cheaper option is self-hosted GitLab CI (but, ugh, maintenance). GitHub Enterprise is so much easier I would gladly pay out the nose for it, though it lags in features.

Next you're looking at Bamboo, TeamCity, Harness, JFrog Pipelines, Spinnaker. Spinnaker is probably the best (only?) open source choice among these.

After that you're looking at open-source projects that come "batteries not included", requiring scripting and integrating more stuff. At that point, my personal preference is to just tie together some AWS or GCloud services, and make your own event-driven task-running pipelines (ex: GitHub webhook triggers Lambda which adds some build items to an SQS queue which triggers more Lambdas which run a build task on Fargate which dumps an artifact into S3 and the end of the pipeline triggers a container build which pulls from S3 artifacts and dumps the resulting container into ECR and test-runs it on Fargate, publishing build results to GitHub commit status). This model is slightly more complex to set up, but insanely easy to scale.

[nilshauk]

Just wondering, what are typical failures with Jenkins that you see?

[peterwwillis]

Mainly it's just that the plugins are buggy and undocumented, and everything requires a massive amount of intoning of unnecessary complexity before you figure out how to make it work the way you want, often manually. Its biggest failure is it's not designed to do things in an automated fashion, and it's overkill for what most people actually need to do: run some build scripts when someone commits something.

[nilshauk]

Thanks for the reply! I guess I wouldn’t fault Jenkins for poor plugin quality unless those plugins are supposed to be officially supported.