Juce & Continuous Integration


#1

Everytime I have a regression bug I think about this CI environment that I did not do…
So to take the 1st step toward implementing this dream, I wanted to ask you guys some questions about how to do it:

I think I need a Hudson server that will invoke the tests upon a GIT commit, but then how will it test it on both Windows and OSX?
Can I make it spawn 2 virtual servers for that ? or that I need 2 Hudson machines for each OS?

What about JUCE commits? does every time I pull the JUCE tip it will run a test or should it run for every commit done by Jules?

And of course, GUI testing, which tools I should use to create some GUI testing scenarios?

And last and most important, do you think it worth doing at all? maybe it’s more like a religious question, but feel free to comment.

Shlomi.


#2

Regarding deployment:
Jenkins (is a hudson fork) provides the possibility to create slave nodes.
You will find some details here:
https://wiki.jenkins-ci.org/display/JENKINS/Step+by+step+guide+to+set+up+master+and+slave+machines

On my side, I use a server hosted on a computer providing services only.
Two slave nodes are connected to this server, one running Windows and the other one running MacOSX.

The Mac node is assigned a label MACOSX and the option “restrict where this project can be run” is checked with the label MACOSX for mac jobs.
Same thing for windows, the windows node is assigned a label WINDOWS, and windows jobs are restricted with the label WINDOWS.
This results in dispatching the right jobs onto the right computers.

Regarding scheduling,
In a general way, the interest of frequently triggering builds and tests is to know precisely which commits produced a failure.
On the other hand, if you reduce that frequency, you should still be able to determine which commit produced this error pretty quickly.

Regarding GUI testing, this topic is difficult and I am also interested in new solutions.

Finally, I use continuous integration tools for continuous build and am willing to get further with automated tests.
These practices are expensive to setup, but very efficient once deployed, strongly recommended by agile methodologies.


#3

Thanks dilig0
Looks like Jenkins is the way to go, I’ll try it.