Ovid <publiustemp-perl...@yahoo.com> writes: > ----- Original Message ---- >> From: Steffen Schwigon <s...@renormalist.net> > > >> AMD just released “Tapper”, an open source test infrastructure with >> automation, machine scheduling, webgui, result evaluation api and >> testplan support. >> [...] >> >> http://developer.amd.com/zones/opensource/AMDTapper/Pages/default.aspx > > > Looks interesting, but did they really release a separate > distribution for every module in Tapper? > > http://search.cpan.org/~amd/
Yes. It's split into subcomponents to allow using only the actually needed functional layers. Examples: - the web application can be run separately - the reports receiver can be separate - the query api, too - several components use the same db schema, which in turn are DBIC::Schema::Versioned so need to be maintained with separate version numbers - The automation layer has carved-out persistently running, never changing parts to allow other parts being updated and restarted without having a downtime. - the automation layer again needs quite aggressive dependencies you don't want to fiddle with everytime when you just need the webapp or install a test machine client. - the cmdline utils are not strictly neccessary everywhere and they in turn share a common functionality layer with the web app - etc., etc., Inside the dists there are actually several bundles, like two db schemas, or the scheduler is bundled inside the automation. Once you have such structure, making reusable parts as yet another separate component is just a consequence. You can only do it 2 ways, completely monolithic or structured by functional dependencies. Monolithic was a real option, thought through for some weeks, but the above reasons ruled it out at some point. And when the libs ran through the CPAN smokers for the first time during the last few weeks it was really helpful to have them divided to conquer. Kind regards, Steffen -- Steffen Schwigon <s...@renormalist.net>
