Great and valid question. Indeed the instances are split by work group. In the "old days" before I assumed the role of build master, developers could only modify jobs on their respective Jenkins instances. But since we've locked down and automated Jenkins, we allow every authenticated user to delete jobs, enable/disable jobs, run builds, whatever. Everything but creating/editing jobs is fair game, because never do we rely on Jenkins as a source of truth for job configuration.
It means we don't have to worry about the problems which will occur when one scales Jenkins vertically, by adding more and more slaves to a single master (a simple example is slower instance startup times due to the increased need to deserialize job configs to memory). Here is a link to Kohsuke's presentation <http://www.youtube.com/watch?v=rygTGn-rqVU> on elastic build environments which briefly mentions horizontal vs vertical scaling. A lot of the Cloudbees marketing material also mentions this well. Cheers, Christian. On Thursday, March 6, 2014 9:02:44 AM UTC-5, LesMikesell wrote: > > On Thu, Mar 6, 2014 at 3:46 AM, Christian Willman > <cew...@gmail.com<javascript:>> > wrote: > > > > But now we have too many Jenkins master instances and many active > branches > > of very similar code, so manually creating jobs via a web UI is too > > inefficient. > > Just curious - what is it that drives the decision to use different > jenkins masters? Would you overload a single master, or are they > split by location, phase of development, work group, or what? > > -- > Les Mikesell > lesmi...@gmail.com <javascript:> > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
