Architecture
Xooctory is designed to address usual continuous integration features with an architecture supporting massive scalability.Massive scalability doesn't mean that Xooctory is designed for outstanding performance but rather that xooctory is able to be deployed on several nodes with as few interaction as possible between the nodes.
Before going further, let's introduce some of the key concepts used in xooctory.
Concepts
- node
- a device with node resources connected to a network (see wikipedia definition)
- node resources
- physical device resources (CPU, memory, disk, network, ...)
- job
- a process which requires node resources to run
- job plan
- what (job resource), when (job plan controller) and how (job procedure) to launch a job. A job plan is responsible to know what a job is about (eg a project at the subversion URL xxx), when to launch it (eg on SCM change and commons-foo-1.1-SNAPSHOT new builds), and how to process the job (eg checkout sources from SCM and launch maven deploy).
- job executor
- a component running on a node, which has the capacity of acquiring device resources on this node to perform a job when the system decides
- dispatcher
- a component running on a node to which the system submit job requests, and which then dispatch these requests to job executors, depending on executors availability, job and executors affinity, and job dependencies
- persistent store
- a centralized location where data about the system can be accessed and updated. Some components in the system only access information, while others make modifications.
- web user interface
- a component used to provide a web UI to the system
- enterprise service bus
- an ESB is a bus where events are sent and listened. Xooctory architecture is an event driven architecture (EDA) which heavily relies on messages exchanged on the ESB
- plugin
- xooctory defines a core architecture in which the actual implementation of how and when to build projects is provided through plugins: components which can be added or removed to the system without damaging its health.
Overview
This simple schema shows how job plan, dispatcher and executor relates to each other. A job plan submit job requests to a dispatcher (which may be shared by several job plan), which in turn dispatch these requests to job executors, which may be on the same machine or not.
Job plans decide when to trigger a job based on events: a change in the corresponding SCM, a dependency that has changed, or simply because of time event (1 hour since last build for instance).
What do not appear on this diagram is the persistent store, to which most of these components access, except the executor (which may be prevented from accessing the persistent store by a firewall). Job executor communicate with the rest of the system through events only (which may be posted via web requests).
Another important component which do not appear is the web UI component. The web UI only need access to the persistent store and the ESB. Thus the web UI do not interfere with the execution of job plans and dispatchers. The web UI can be clustered on several nodes to handle a high number of users accessing the web interface. There is no correlation between the number of web UI nodes and the number of dispatchers or job plans: in some cases a very high number of job plans will require a high number of executors and dispatcher, whlie the web UI will seldomly be accessed and thus requiring only a limited number of resources.
This architecture is what is supported by xooctory, it doesn't mean that you need to deploy a xooctory installation on several nodes. In simple cases all components can run on the same node.