Almost 7 years ago, we set up our first build pipeline and I was a bit anxious about Jenkins because I simply hated it and it would have been the only piece of Java technology in our stack. Our infra guy basically told me "look, there’s nothing more powerful and widely known out there" (which was pretty much true at the time, at least in open source) and had already set up the VM when Gitlab came out with their CI/CD.

Since we just had set Gitlab up as our source control platform, this was the logical choice and we immediately ripped down the Jenkins server. Since we were still starting out, integration and rewiring was done in just a day.

I‘ve never been so happy playing the early adopter guinea pig. Actually we never had any real issues with it and aren‘t looking back.

For me, powerful equals "footgun included". CI should do one job and do it well imho. Huge bonus points for tight coupling into the source control workflow.

Your mileage may vary.

Jenkins to me is great for prototyping certain process activities in a very arbitrary set of conventions, but it provides a lesson as to why the Java world moved on from tools like Apache Ant (XML-based Make) to Maven (convention over configuration as a tooling value). While 10 years ago such processes were not really standardized nowadays people are used to conventions like GitOps with well documented processes for how artifacts are built, deployed, and operated with container primitives after we've spent a _lot_ of time now trying to manage Jenkins installations that become incredibly brittle over time and become more of a liability than a force multiplier for the organization. So people are adopting more specialized tooling instead of trying to have Jenkins do everything under the sun from building artifacts to deploying them to deploying infrastructure with CD conventions.

Things I've found better than Jenkins once an organization lets go of over-engineered processes:

- TeamCity - Concourse CI - Circle CI - ArgoCD - Tekton

For Windows build agents I've met plenty of people successful with Octopus Deploy that have hated Jenkins and your data point is the first I've seen that went back to Jenkins.

Perhaps it's worth looking at Team Foundation Server / Azure DevOps?

Octopus Deploy and TeamCity are horrific. Jenkins is hilarious better despite all of its flaws. Concourse CI has a higher learning curve than Jenkins (at least for users, not necessarily admins), but once you get it, it's definitely a good contender. CircleCI is great!

I've used Jenkins for a long time, long enough to have used Hudson (Jenkins is a fork of Hudson due to Oracle drama).

The alternatives listed in reply to your thread are all much better than Jenkins, from system design, to usability, to cost of ownership of the personnel needed and tech debt incurred. Here's my own opinionated list, having used or evaluated them before:

1. GitlabCI 2. Circle CI 3. Travis CI 4. Github Actions 5. TeamCity 6. Concourse CI

Jenkins just happen to have been around a long time. It's like Jira -- everyone uses it, but nobody likes it.

Jenkins has an important niche: "overgrown or enterprise projects that were initially created without ci in mind and require a ugly, hacky pipline to build"

I think it still has no rival in that area and it's also why is getting a bad rep.

Buildkite might be an option in a regulated environment.

They don't get access to your code (BYO runners, they manage pipeline config / logs / notifications). You run their (open source, easy to build yourself) agent on infrastructure you control.

It's really nicely put together.

Buildkite's problem is they only support git, unfortuantely.

https://buildkite.com/docs/agent/v3/hooks indicates you can override the builtin git support with your own checkout system. Sucks having to write a plug-in but it should be short.

Somebody already has, for perforce:

https://github.com/improbable-eng/perforce-buildkite-plugin

I've looked into this plugin before (we also use perforce). This does techincally let you build from perforce, in the same way making `p4 sync` your first build step does.

What are your requirements? The most recent CI/CD system I've used was Concourse, and using it was great - it's very flexible, if a bit barebones. (I didn't have hand in the initial installation for it, so this is only for using it)

https://concourse-ci.org/

Gitlab CI.

I think you missed that I'm using Perforce; gitlabCI would be a super hack job.