3

Background:

I'm a SW developer who has some experience configuring continuous integration solutions, but I am not very familiar with the pluses and minuses of certain continuous integration strategies, and would like advice as to the benefits and challenges of two server management strategies.

Question:

We have 3 separate, complex, Android applications for which I am creating continuous integration servers. I've successfully created a prototype virtual machine running Windows Server 2008 which successfully compiles the code, launches an emulator and runs android unit tests. Separately I have also been able to run the static analysis that we wish to run on this code to provide developers with feedback.

In previous configurations using CruiseControl.NET instead of jenkins, we had success in maintaining 3 separate virtual machines, all with independent virtualized hardware. The benefits of this setup is compartmentalization - one project can change their build server without the other project being affected.

However, moving to Jenkins, I note that it supports master/slave nodes, which could allow me to configure one Jenkins master instance with multiple projects, and then configure a number of slave nodes which, as I understand it, would perform any Jenkins tasks - the compilation, unit testing, static analysis and pass this information back to the master server. The benefits of this setup seem to be:

  • Scalability - I can easily add a 4th or 5th project and maintain the same number of slaves
  • Requires setup of only 1 master and 3 slaves, which is probably easier to setup than 3 separate masters.

Challenges with this situation appear to be:

  • I'll have to learn how to create slaves
  • I'll have to handle the communication between the clients and slaves
  • I may have issues running unit tests that require UI interaction - post describing how to run headless slaves

Are there any other immediate benefits or challenges that I have forgotten, or does someone who has experience setting up jenkins have an opinion as to which approach would be more appropriate?

Community
  • 1
CrimsonX
  • 133
  • 1
  • 4

1 Answers1

5

Your understanding is quite complete. The only thing i can add are that "master/slave" terminology use in jenkins/hudson is a little corrupted in my opinion. As the "slaves" are more like executors in distributed scheme of triggering jobs/builds/projects. I won't think that having 3 separate jenkins masters is reasonable in your situation.

1) - I'll have to learn how to create slaves - This is not really a concern, it is just one jar file for the slave. Can be installed on different OS quite easily (Linux, Windows, Unix) can be ran as a service/daemon. Then you will just have to attach that slave to the master.

2) I'll have to handle the communication between the clients and slaves - This is quite trivial as well, as all you need is manage the ssh keys and user account for the slaves to connect to clients.

3) I may have issues running unit tests that require UI interaction - That again should not be an issue. There should be plenty solutions by now.

Again I really do encourage you to utilize jennkins in your development workflow for CI and CD, there are really no things that jenkins cannot do what comes to it. Started using it 3 years ago and never looked back.

The only corner stone I see in your particular situation is that it is a new tool and and there is might be a little learning curve and some adjustments to make while migrating from old workflow, but most likely it will greatly benefit you and your team in the long run.

Hope this helps.

Danila Ladner
  • 5,331
  • 22
  • 31