v 0.1

This is the first public version of Xooctory, developed in only a few weeks, so do not expect a feature rich application for the moment.
Despite its young age, it is already able to fulfill some basic continuous integration needs.

Moreover, due to the powerful technologies used, Xooctory already provides a very flexible architecture.

Two libraries are at the core of this flexibility: springframework and Mule.

The spring framework ensure a high level of flexibility in services: you can easily plug your own agents, your own builders, or your own web views very easily.

But one of the biggest strength of Xooctory is its event driven architecture leveraging Mule. Indeed Mule is an ESB which is able to trigger events from a lot of different channels (or transports, in Mule terminology).
Since most of Xooctory services are triggered by events and trigger themselves events, you can benefit from this set of transports now.
For instance, each step of build jobs in xooctory fires an event, thus you can very easily trigger any of Mule facilities at any of these steps: build finished e-mail or instant message notification, file publication, custom database update, web service call, ... We let you imagine what you can do with that!

So, besides relying on wonderful technologies, here is what the v0.1 version offers:
Flexible build triggers
Build can be triggered by any Mule event. This means that you can trigger the build on e-mail reception (e-mail notifications of commits is available with most SCM tools, including CVS and Subversion).
It's actually the only way to trigger builds, which means that as of v0.1 Xooctory do not support SCM polling.
Ant based builds
For the moment Xooctory only supports Ant builds, launched as an external process (you need to have ant installed on your box in order for this to work).
But you can pretty easily write your own builder (and even contribute it), or launch whatever you want from the ant script (a build shell, maven, ...).
However, keep in mind that only logs and result status of this in ant build is known and stored by xooctory for the moment.
This is something that will evolve much in a close future, stay tuned!
Full history of builds
Each build time and result is stored in a database, allowing to keep track of the status of your builds over time.
Thread safe build queue and distributed agents.
The core of xooctory is its job queue (also called job scheduler), which has been designed for thread safety, which is an important requirement in event driven system like xooctory.

The job queue is responsible for job scheduling, dispatching jobs on agents.
The testing of the thread safety of the scheduler is part of the important test suite used in xooctory, which test the concurrent access to the scheduler to schedule thousands of jobs on thousands of agents.

Communication with agents is asynchronous and designed to address failures, so that you should be able to distribute agents over the network (even if this has not been tested yet, but it will be one of our strong focus in the future).
Web based UI
Even if the UI is still pretty basic for the moment, you can already access to:
  • a dashboard displaying the list of projects, agents and to the build queue status
  • a project page allowing to access to the history of builds and gathering some stats and information on the project
  • a build page displaying the status and logs of any build, including instant feedback during a build
Instant feedback
Xooctory reports its activity as it occurs, so that you always know what is currently going on. You can easily follow a build as it is processed by looking at its real time logs provided in the web UI.
The push mechanism used for the moment is very basic and experimental. Moreover it relies on polling, which is not very scalable and reactive. We plan to use comet or similar techniques in the future.