www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject [scm] Use case: Continuous integration
Date Sat, 01 Mar 2008 12:06:11 GMT

Continuous integration tools would probably be worth a whole topic of
their own, but since they are related to version control I'm taking
them up within this scope as well.

Use case: Someone (either within or outside Apache) sets up a
continuous integration system and wants to get the latest sources from
the source repository. Optimally the system would automatically
compile, package, and test the sources after each commit, but hourly,
daily, or weekly builds would also be acceptable depending on the
scope of the tests and available computing resources.

Variants and implementation options:

1) Push-based CI: The SCM system would notify the CI system of all
source changes so that the system can start processing the changes as
soon as possible. Currently the best way to achieve this would
probably be to subscribe the CI system to the relevant -commits
mailing list, but other alternatives might also be possible. Assuming
there are enough computing resources either at Apache or an external
CI lab for such potentially high-frequency integrations, would the
associated load on our Subversion server be acceptable? If not, how
could we resolve such issues?

2) Pull-based CI: The CI system regularly polls the source repository
for new changes. Again, assuming enough CI computing resources, what
would be the smallest acceptable polling interval from the perspective
of our Subversion server. Are there other considerations that such CI
systems should be aware of when accessing the source repository?

Related to this and some of the other raised issues, would it be a
good idea to consider one or more read-only mirrors of our Subversion
repository. I'm not sure how feasible such mirroring would be with
current Subversion, but in the long run something like that seems more
scalable and fault-tolerant than upgrading a single svn server.


Jukka Zitting

View raw message