Thank you very much for your feedback ! I think we're going to explore the idea of creating one or more physical hosts creating VMs. Do you use a particular tool or plugin to create those VMs 'on the fly' or do you create them manually ?
thank you again! Le mercredi 26 septembre 2012 18:25:48 UTC+2, Mandeville, Rob a écrit : > > Having the Jenkins server on a host that doesn’t run builds isn’t just > interesting, it’s a good idea. The only downside that I see is that the > slave-master communication (probably dominated by your build logs and > artifacts) is slowed down to network speeds rather than the speed of your > loopback adapter. I’m running in this configuration with 170+ slave nodes > scattered across over a dozen build hosts (each build takes up a user > account, so we need multiple slaves per host). We basically build 60 > different SCM branches of the same project. > > > > Multiple masters can be useful. I have one master for my build jobs, > another one for housekeeping (I find it better than cron because it’s more > visible and doesn’t spam you with email, and it’s also useful for some of > your more routine command lines), and some people on a side project set up > their own. Part of the question is organizational: Jenkins is small enough > that somebody working on a small project can set their own up, if they’re > willing to spend a little of maintenance time. That can keep you less > involved in smaller projects, if this sort of a thing is acceptable to your > organization. > > > > --Rob > > > > > > > > *From:* jenkins...@googlegroups.com <javascript:> > [mailto:jen...@googlegroups.com] <javascript:> *On Behalf Of *mpapo - > Michaël Pailloncy > *Sent:* Wednesday, September 26, 2012 8:58 AM > *To:* jenkins...@googlegroups.com <javascript:> > *Subject:* Feedback of your CI architecture > > > > Hi all, > > > > Currently, we manage near 250 jobs related to several java projects and > several teams in our company. > > > > Our CI architecture characteristics : > > - a Jenkins master on AIX 5.3 with 8 processors and 10 GB of RAM > > - 3 RHEL slaves with 2 processors and 4 GB of RAM > > - 2 Windows slaves with 1 processors and 2 GB of RAM > > > > We arrive sometimes has limitations with Jenkins. Especially during > releases. > > > > Due to an increase of job number in our Jenkins in my company, we want to > change our architecture to meet our needs. We are going to manage near 500 > jobs. > > We want to switch the master on a RHEL OS (our new main target platform) > and add an AIX slave for projects that need this platform. > > > > Here are our thoughts : > > - Do you think it would be interesting to have a master only used to > monitor the jobs (0 executor, all builds are delegate to slaves) ? > > This could be interesting to have a more stable and more reliable master. > > > > - On the other hand, do you think it could be interesting to use multiple > masters ? One for each team for example ? > > This could be nice to have a more specialized master per team but I guess > it must increase the maintenance time. > > > > > > I need feedbacks from the community to choose the best architecture : > > How many jobs do you manage ? > > What are the characteristics of your architecture ? (number of slaves, of > master ??) > > Would you prefer to use a slave with large capacity, or more with > capacities smaller? > > > > > > Thanks in advance from any help and feeback ! > > > > Michaël Pailloncy > > > > > The information in this message is for the intended recipient(s) only > and may be the proprietary and/or confidential property of Litle & Co., > LLC, and thus protected from disclosure. If you are not the intended > recipient(s), or an employee or agent responsible for delivering this > message to the intended recipient, you are hereby notified that any use, > dissemination, distribution or copying of this communication is prohibited. > If you have received this communication in error, please notify Litle & Co. > immediately by replying to this message and then promptly deleting it and > your reply permanently from your computer. >
