I can't speak for other countries but in London a lot of companies are now using Gitlab or Circle CI.
I migrated all my builds (12 projects) to Gitlab CI. After figuring out the first CI pipeline using DockerInDocker, it was easy to then setup the remaining pipelines.
Self hosting Gitlab was perfect for our needs (private docker registry). I use Gitlab for personal use too.
I wonder if they will get rid of Ruby in the future though and go Java to make it more performant, as it does slow down sometimes.
The Jenkins box is still running though, more out of sentimental value :)
We're working on making GitLab more performant. It is mostly fixes to our code, the parts where ruby is a problem are already rewritten in Go. GitLab self-hosted should be fast if it has enough memory, so make sure you check on its memory consumption.
> The current legacy version of Jenkins needs to be restarted once a day by an administrator
Is this true? Do you have a source that says this? We have a Jenkins instance that Kubernetes is configured to scale down from 1 replica to 0 at night, and up to 1 again in the morning, so if it is true we never would have noticed. (It hasn't always run on this cron cycle, which is why I'm a little incredulous at this claim, but if it's given in the OP or somewhere else easy to find this, I'll concede it... ah... found it: > It’s not unheard of that somebody restarts Jenkins every day.)
Honestly I don't understand this about "making a version of Jenkins that runs well on Kubernetes" – this is the _only way_ I have ever run Jenkins, and I think it runs already extraordinarily well for our purposes. I'm thrilled that they are making it their focus, and I'll concede also that our use of it is pretty narrow, but I haven't had these issues.
We installed it from the stable helm chart nearly 2 years ago and have hardly needed to make any tweaks. We are not tracking every K8S release, so maybe that's why I haven't noticed Jenkins falling behind, and we also haven't tried GitLab seriously (heard great things, but my work is very risk-averse when it comes to new technologies, and to be honest we rarely try new things on a short cycle once a given problem has been solved adequately for us... we are also not primarily a development shop, so maybe it makes sense.)
> The article doesn't mention how Cloud Native Jenkins addresses the problem, maybe it doesn't allow plugins.
Like I've been saying, we've always used the stable helm chart for Jenkins and started maintaining our own values.yaml about a year and a half ago. Over time we have had less need to change the templates as more configuration got moved into values.yaml. When I have needed a plugin or other configuration that is able to be set in values.yaml, that's easy and almost makes maintaining Jenkins fun. It is a little obtuse that I have to maintain my list of plugins and their latest versions there manually, but this could be something that gets resolved in Cloud-native Jenkins if they are ultimately providing an operator or something like that.
(Breaking a rule by commenting before I've read all of the content, but I liked your article and wanted to give you some feedback since you posted it.)
For configuration that doesn't live in values.yaml, Jenkins chart maintains a Persistent Volume where configuration and build artifacts/history are stored. It is easy enough to take backups of that with the ThinBackup plugin, and the storage costs of that are sure not breaking the bank.
> Services interacting through Kubernetes CRDs in order to promote better reuse and composability
And there it is! That's the big announcement from today. Knative is still early but this news from Jenkins sounds supportive and I should really read the whole article / watch the video now.
>>> The current legacy version of Jenkins needs to be restarted once a day by an administrator
>Is this true? Do you have a source that says this?
The OP states: "Admins today are unable to meet that heightened expectation using Jenkins easily enough. A Jenkins instance, especially a large one, requires too much overhead just to keep it running. It’s not unheard of that somebody restarts Jenkins every day."
> Honestly I don't understand this about "making a version of Jenkins that runs well on Kubernetes" – this is the _only way_ I have ever run Jenkins, and I think it runs already extraordinarily well for our purposes.
I think the idea is not that Jenkins runs on Kubernetes, which as you note can already be done. It's rather that Jenkins uses Kubernetes as a replacement for the worker infrastructure.
This can be done with plugins, kubernetes-plugin for example. I'm looking forward to seeing what they come up with. It was good to see knative on their roadmap! This could be something else majorly.
"in London" suggests that geography is the primary driver of your first-hand experience, rather than tech stack or company type. I've been working in London for a decade, and i don't think i've ever used either Gitlab or CircleCI for CI!
That said, i haven't used Jenkins for several years either.
I can't speak for other countries but in London a lot of companies are now using Gitlab or Circle CI.
I migrated all my builds (12 projects) to Gitlab CI. After figuring out the first CI pipeline using DockerInDocker, it was easy to then setup the remaining pipelines.
Self hosting Gitlab was perfect for our needs (private docker registry). I use Gitlab for personal use too.
I wonder if they will get rid of Ruby in the future though and go Java to make it more performant, as it does slow down sometimes.
The Jenkins box is still running though, more out of sentimental value :)