I'm in a bit of a bind with our Jenkins setup at a company with around 1500 employees. Our self-hosted Jenkins is currently managing about 450 concurrent jobs, but that number is on the rise. I'm debating whether to just keep adding more hardware or to look into CloudBees, which offers features like horizontal scaling. I'm really interested in hearing about your experiences to help me determine the tipping point for making this switch.
If you're a CloudBees user, what challenges drove you to make the change? Did it really help with scaling issues and was it worth the investment? And for those managing Jenkins on their own, how have you handled scaling? Is there a genuine limit to just boosting hardware? I'm looking for some real-world insights. Thanks!
3 Answers
We went with a master-slave architecture. When we need more processing power, we just clone a Jenkins machine, set it up, and connect it to the master. It’s a pretty effective way to scale without going overboard.
Honestly, I'd say just run! Scaling Jenkins can get pretty tricky, and sometimes simpler solutions are better!
We've had great success with Jenkins Configuration as Code (JCasC). It lets you store configurations as YAML, which is super handy for maintaining approved plugins and security settings. Scaling is straightforward, allowing different teams their own instances if RBAC is set up properly. Plus, testing new plugins and disaster recovery become much easier—just deploy another instance in the cluster! Definitely worth exploring JCasC for your scaling needs.
I get what you're saying, but updating Jenkins isn't always a walk in the park. You'll still face plugin compatibility issues that can complicate upgrades. Sometimes I think JCasC makes it worse, since it can break when plugins aren’t supported or if new syntax comes into play with version updates.
Exactly! Avoid unnecessary Jenkins plugins when you can and just keep it simple—like running Python jobs from GitHub. It helps to have it behind a firewall too.