Eric Noulard wrote:
> 2007/2/21, Stephane GALLES <address@hidden>:
>> Frederik Deweerdt wrote:
>> > On 2/20/07, Stephane GALLES <address@hidden> wrote:
[...]
>> >>
>> >> I don't have a continuous integration server up 24/24, but
>> >> I can offer to write the cruisecontrol configuration file
>> >> and the build script adapter and someone could deploy a cruisecontrol
>> >> configuration in a Tomcat on a real build server.
>
> I don't think we should really a "build server"
>
> Each TSP developer box may be used as a build server
> which sends report at the end of the build loop which has
> run locally.
Not a good idea. Explanations below.
>
> I really don't know if cruisecontrol is supposed to support this
> but seems to me more easy to obtain than a networked
> build server.
No, quite the contrary. It would be easier to obtain one single
continuous integration server, because one single server in enough
for all developpers. More than one integration server is kind of
meaningless. And, this server does not need to be remotely accessible.
Let me summarize how a continuous integration server is supposed to
work, in order to explain why... :
1 - it is very easy to setup, with almost no maintenance once set up.
2 - you really need only one integration server, and only one.
3 - preferably, you don't want this integration server to be one of the
developpers desktop, but, at worst, it may be the case
4 - If the continuous integration server is on a desktop (bad idea at
first), you really don't want the continuous integration to have
something to do with any manual activity on the desktop (and especially
NOT the developpement activity of the user). And
you REALLY, REALLY, REALLY don't want to test the build on the
developper's check out directory.
Whatever the continuous integration software (ci software) you choose,
the basic principle is always :
1 - The ci software runs as a service on the ci server. Every x minutes
(let's say every 15 minutes) the software contacts the source version
server (CVS, SVN...) that can be on an other server, and ask for the
last check in date and time.
- If a recent check in is detected by the ci software (by comparing the
last checkin in date), the ci software deletes its local build
directory, and do a complete check out of the project, and try to build
the project.
- If the build succeeds, and if there're sanity of unit test in the
project, the ci software tries to run the tests.
- If etheir the build or the tests fail, the ci software send an ERROR
email, including the last changeset (list of checked in files that broke
the build) to a list of email addresses, or to a mailing list.
- then the ci software, keep on watching the last check in dates and
does nothing more.
- If a new ci is detected, the ci software retry to build the project
- In case of an other faillure, an other ERROR email is sent. It
will happen for all check in if the build is not fixed
- if the build succeds, a SUCCESS email is sent.
- From now on, all the following check in won't trigger any new email
sending if the build succeeds.
- go to step 1
So, with this scenario, why :
1 - it is very easy to setup, with almost no maintenance once set up.
Because, it works almost alone, and can work behind a firewall as the
ci server does not need to be seen from the internet. It only needs to
be able to do check out from the source control server. No security
problem at all, all the more so as the ci server never do any check in ;
he can do its check out as an anonymous source control user.
2 - you really need only one integration server, and only one.
I think it is self explanatory.
3 - preferably, you don't want this integration server to be one of the
developpers desktop, but, at worst, it may be the case
For several reasons :
- whenever a build occurs, it may bother the user (CPU 100%)
- the PC might not be up all the time
- but mainly : you want a ci server to act as a neutral reference
configuration. You do not want a continuous build to succeed because
on this particular PC, the developper has installed a particular version
of a library (maybe the same version that makes its code
compile...hum...only on his own desktop...)
4 - If the continuous integration server is on a desktop (bad idea at
first), you really don't want the continuous integration to have
something to do with any manual activity on the desktop (and especially
NOT the developpement activity of the user). And
you REALLY, REALLY, REALLY don't want to test the build on the
developper's check out directory.
- self explanatory, you do not want to rely on a user to trigger
the build by hand. A ci server is especially good at catching the
error of type "I do not rebuild because I've only changed a comment"
and I have changed the enconding of the file because I've opened it
with a bogus editor...
- the build must be done in a clean directory, you do not want the
build to succeed because a file the developper has forgotten to check in
is in this directory.
>
> We may open a tsp-build mailing list which receives build
> loops reports from any (but identified) build server.
Yes, good idea, it allows to configure only this email address
in the ci software, and let the user register to the mailing
list on they own.
[...]
>> > Not to
>> > mention a build server could act as a subversion server ;)
>>
>> Exactly :)
>
> That's just where I do not understand.
> Our configuration server is Savannah which surely won't be
> a build server anytime soon no?
You're right. that why the shortest path to a ci server for TSP
is a PC, behind a firewall, that watches the source control on
Savannah (at worst, a developper's PC)
By agreeing with Frederik, I meant that is was a possible as an usual
configuration to have both the ci software and the source control
software on the same PC.
>
>>
>> It is even a very usual set up. (Actually that's what this dedicated
>> Linux distro does, http://buildix.thoughtworks.com/, but only for a
>> LAN, not a WAN, as the security is not managed).
>
> I understand that but I think it does not fits what we may afford
> TODAY since we have no "networked server" for installing such tools
> unless anybody here wants to offer such access :))
As I said, no access needed. Whatever old PC behind whatever home
firewall will do the trick. I could set it up on my own PC, but it
is not up all the time.
But maybe someone owns an old Pentium that sleeps in a cupboard ?
Stephane.
_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel