continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject separating the builder code from the UI
Date Fri, 11 Apr 2008 06:48:18 GMT

I've been thinking ahead a bit about a potential design change I'd  
like to make. At the moment, at a very coarse level, we have the  
"Core" which does just about everything :), which is comprised of a  
few modules, and the webapp/xmlrpc sitting on top of that. It looks  
something like [1]. It is pretty well separated from the UI, but the  
parts of the core are not well separated and hard to test, and the  
store/model is pervasive through everything.

I would like to propose factoring out the bit that does the building,  
something like [2].

This is not a totally radical change, though it will change the  
workflow a bit such that:
* the builder has no database interactions. So it will be on the  
return events that contain results that get persisted in the database
* notification will be based on the return events, not part of the  
build logic

Clearly demarcating where the database is used is a Good Thing I feel,  
and it then becomes a way to store and visualise results.

There are a couple of potential things that will later be possible  
with this architecture:
- the requests could be made over REST and the events sent back over a  
JMS Q similar to GBuild - allowing us to move the builder to an  
entirely different server, and to have multiple builders. If each has  
a given set of installations/environment profiles we can then  
aggregate results for different platforms
- you could run Continuum with just the bottom layer for a really  
simplified system. The only change we'd make here is that you'd hook  
up the notifiers and other event responses directly instead of the Q

I'd like to attempt this on a branch, making the minimal amount of  
change possible to see how it works. What do others think about this  



Brett Porter

View raw message