This page describe the features that Xooctory will provide in its final 1.0 version, which has not been released yet.
To get an overview of the features currently implemented in Xooctory, please check the Release Notes.
Xooctory is a continuous integration and build server, with a strong focus on the following features:
Open Source
Xooctory is developed as an open source project, with an open source business friendly license, and following an open development.
This means that you can use Xooctory free of charge, and you can also follow the developments with the mailing lists, ask questions, contribute feedback, submit issues, submit patches and even become a member of the team if you prove reasonable skills and high commitment to the open source philosophy.
If you are interested in top level server side development, with fancy and reactive web UI, complex algorithms dealing with high concurrency and distribution, join us and get involved!
This means that you can use Xooctory free of charge, and you can also follow the developments with the mailing lists, ask questions, contribute feedback, submit issues, submit patches and even become a member of the team if you prove reasonable skills and high commitment to the open source philosophy.
If you are interested in top level server side development, with fancy and reactive web UI, complex algorithms dealing with high concurrency and distribution, join us and get involved!
Massive scalability
The aim of Xooctory is to be able to handle both small projects and huge development departments, distributed across the world, by providing a massive scalability.
By massive we mean that we intend Xooctory to work with millions of builds, thousands of projects and users, running on hundreds or thousands of nodes with heterogeneous performance and reliability.
We are currently discussing with the University of Bordeaux I to collaborate to leverage their expertise and their testing infrastructure in this area.
To provide this kind of robustness and scalability, we leverage rock solid and proven server side technologies such as the Spring Framework and Enterprise Service Bus, as well as peer to peer communications between agents to optimize the resource consumptions and avoid any single point of failure.
By massive we mean that we intend Xooctory to work with millions of builds, thousands of projects and users, running on hundreds or thousands of nodes with heterogeneous performance and reliability.
We are currently discussing with the University of Bordeaux I to collaborate to leverage their expertise and their testing infrastructure in this area.
To provide this kind of robustness and scalability, we leverage rock solid and proven server side technologies such as the Spring Framework and Enterprise Service Bus, as well as peer to peer communications between agents to optimize the resource consumptions and avoid any single point of failure.
Flexibility
The philosophy of Xooctory is to provide a robust and flexible architecture fulfilling common needs out of the box, but allowing to adapt to any situation and environment via customization and plugins.
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.
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 and receive events from a lot of different channels (or transports, in Mule terminology), in a very robust and scalable way.
Since most of Xooctory services are triggered by events and trigger themselves events, you can leverage the transports provided by Mule to customize the behavior of Xooctory.
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, ...
Moreover, triggering events through this wide set of transports can also be very interesting: trigger a build through a web service call or by sending an e-mail, add a user or a project by dropping a file in shared directory, ...
We let you imagine what you can do with that!
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.
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 and receive events from a lot of different channels (or transports, in Mule terminology), in a very robust and scalable way.
Since most of Xooctory services are triggered by events and trigger themselves events, you can leverage the transports provided by Mule to customize the behavior of Xooctory.
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, ...
Moreover, triggering events through this wide set of transports can also be very interesting: trigger a build through a web service call or by sending an e-mail, add a user or a project by dropping a file in shared directory, ...
We let you imagine what you can do with that!
Build dependency aware
More and more projects are developed as a set of interdependent modules, and it doesn't always make sense to build a whole project from scratch when only one module has changed.
Indeed this may lead to quick exhaustion of CPU resources, increased delay before feedback on the status of your project, and even erroneous feedback. For instance if a module has a dependency which has changed its API or contract and do not build any more, should you revert the changes in the dependency? But maybe those changes are volunteer and should not be reverted. Should you update the main module to adapt to those changes? In theory, yes, but maybe it's not the appropriate time to do so. So there are cases where keeping control over the dependencies between your modules is important.
That's why Xooctory is designed to be dependency aware, leveraging Ivy to manage the dependencies between the modules, and rebuild exactly what is necessary, in the correct order, blocking builds when a dependency is currently building, and so on.
Indeed this may lead to quick exhaustion of CPU resources, increased delay before feedback on the status of your project, and even erroneous feedback. For instance if a module has a dependency which has changed its API or contract and do not build any more, should you revert the changes in the dependency? But maybe those changes are volunteer and should not be reverted. Should you update the main module to adapt to those changes? In theory, yes, but maybe it's not the appropriate time to do so. So there are cases where keeping control over the dependencies between your modules is important.
That's why Xooctory is designed to be dependency aware, leveraging Ivy to manage the dependencies between the modules, and rebuild exactly what is necessary, in the correct order, blocking builds when a dependency is currently building, and so on.
Instant feedback
Ever wondered what your continuous integration server is currently doing? Ever waited hours before a build result? Ever called refresh twice a second to get an up to date view of your projects status?
Forget about that! Xooctory provides instant feedback on what is going on in your continuous integration and build system.
You can view your build logs while the build is performing, even on a distributed agent.
You can get unit test results when they are performed, or even be notified (via e-mail or IM, or whatever you prefer) as soon as one test fails, instead of waiting for the whole build failure.
The web interface provided leverages push mechanism based on comet to provide instant update of the information on the page.
We also implement and favor SCM triggered builds instead of SCM polling, to get your build starting right after your changes in the SCM, without having to slow down your SCM install due to regular polls.
Forget about that! Xooctory provides instant feedback on what is going on in your continuous integration and build system.
You can view your build logs while the build is performing, even on a distributed agent.
You can get unit test results when they are performed, or even be notified (via e-mail or IM, or whatever you prefer) as soon as one test fails, instead of waiting for the whole build failure.
The web interface provided leverages push mechanism based on comet to provide instant update of the information on the page.
We also implement and favor SCM triggered builds instead of SCM polling, to get your build starting right after your changes in the SCM, without having to slow down your SCM install due to regular polls.
Detailed reports
Xooctory provides fine grain detail on the overall quality of your software, with line precise and historic information about your compilation warnings and errors, you unit test results, your javadoc generation, your code coverage and your code quality audit with checkstyle, PMD, findbugs and others.
Xooctory flexible architecture let you collect any kind of quality data during your build, and present the information through trends and charts, including evolution from one build to another, and correlation with users.
Xooctory flexible architecture let you collect any kind of quality data during your build, and present the information through trends and charts, including evolution from one build to another, and correlation with users.
Security
Xooctory is designed to be secured and to leverage user profiles to provide user specific access to the information.
This means that you can give a restricted access to your customer on your Xooctory install to allow them to get feedback on the current quality of your project and development effort. You can allow developers of one project to access only this project, you can restrict some users to trigger actions on your system, you can hide part of the web UI, like the agents view, to a particular user or role.
Security also mean that you are attentive of not disclosing confidential information where it doesn't need to be, that artifacts can be signed and verified when transported between nodes, that you can use secured channels for communications between nodes or on the web UI, and so on.
This means that you can give a restricted access to your customer on your Xooctory install to allow them to get feedback on the current quality of your project and development effort. You can allow developers of one project to access only this project, you can restrict some users to trigger actions on your system, you can hide part of the web UI, like the agents view, to a particular user or role.
Security also mean that you are attentive of not disclosing confidential information where it doesn't need to be, that artifacts can be signed and verified when transported between nodes, that you can use secured channels for communications between nodes or on the web UI, and so on.
Web based UI
A web based user interface let you access information about your projects with ease.
All actions on the projects and the builds can be done with the web interface, leveraging technologies like AJAX and comet to give up to date information in a clean and attractive way.
Xooctory use charts, colors and icons when appropriate to let you access to a wide range of information as quickly as possible.
All actions on the projects and the builds can be done with the web interface, leveraging technologies like AJAX and comet to give up to date information in a clean and attractive way.
Xooctory use charts, colors and icons when appropriate to let you access to a wide range of information as quickly as possible.
Integration
Objectives of the Xooctory project are already very high, so at the moment we have decided to concentrate our effort on a small integration with external build tools. This may change in the future if the team gets bigger and if people are interested to provide more integration (the flexible architecture allow to easily provide new integration), but our first objective is to integrate with:
- Subversion One of the most popular SCM at the moment
- Ant+Ivy A rock solid, proven, and flexible base for complex build systems.
