Comparing CI build tools: Cruise Control and Hudson
|
|
| ||
| 1 | Open Source | 1 | Open Source |
| 2 | Easy installation: Just java -jar Hudson.war, or deploy it in a servlet container. No additional install, no database. | 2. | It also gives us very easy installation. Just unzip the downloaded zip file. That’s it. It is actually using an internal Jetty server. No Database, no install here also. |
| 3 | Easy configuration: Hudson can be configured entirely from its friendly web GUI with extensive on-the-fly error checks and inline help. There’s no need to tweak XML manually anymore, although if you’d like to do so, you can do that, too. | 3. | Big difference comes here. The GUI providing by Cruise control for configuration is not at all good. It just displays the config.xml file.  Its no way near to Hudson for Configuration GUI part. If you want to configure Cruise Control then you must study about the structure of the Config.xml first. |
| 4 | Change set support: Hudson can generate a list of changes made into the build from CVS/Subversion. This is also done in a fairly efficient fashion, to reduce the load of the repository. | 4. | Cruise control also show the list of files which are changes at this check-in process. |
| 5 | Permanent links: Hudson gives you clean readable URLs for most of its pages, including some permanent links link “latest build”/”latest successful build”, so that they can be easily linked from elsewhere. | 5. | Uhm… Cruise control is not giving this. It gives a link with some log code number attached with it. Its looking horrible and cant be easily likable. |
| 6 | RSS/E-mail/IM Integration: Monitor build results by RSS or e-mail to get real-time notifications on failures. | 6. | It also gives RSS and email functionality. Don’t know about IM support. If we need to change the Email structure then either we have to change XSL or CSS file which we are using in the email config. |
| 7 | After-the-fact tagging: Builds can be tagged long after builds are completed | 7. | N.A. |
| 8 | Detect new failing tests while build | 8 | Failing tests will show in the dashboard. But no separation between new and old. |
| 9 | Notify when first test in build fails | 9 | No such type of notification. |
| 10 | JUnit/TestNG test reporting: JUnit test reports can be tabulated, summarized, and displayed with history information, such as when it started breaking, etc. History trend is plotted into a graph. | 10 | It is showing all the unit test results but not as good as Hudson does. There is no detailed information like when it started breaking, History etc. and no graph for unit results too. |
| 11 | Distributed builds: Hudson can distribute build/test loads to multiple computers. This lets you get the most out of those idle workstations sitting beneath developers’ desks. | 11. | The build distribution is done through the maven install goal. Its |
| 12 | File fingerprinting: Hudson can keep track of which build produced which jars, and which build is using which version of jars, and so on. This works even for jars that are produced outside Hudson, and is ideal for projects to track dependency. | 12. | No idea. |
| 13 | Plugin Support: Hudson can be extended via 3rd party plug-ins. You can write plug-ins to make Hudson support tools/processes that your team uses. | 13. | Plug-ins are there in Cruise control also. |
| 14 | Dash board: Hudson has an attractive dashboard with Colorful as well as meaningful icons. We can separate this building projects into subgroups also. It will also shows building projects. Well designed Ajax pages. | 14. | It gives an attractive Dash board. It displays all the necessary information which we need to know. We can directly build from there also. Viewing/ downloading the log file is also allowed from this Interface. |
| 15 | Local Copy of projects: Handled by Hudson itself. No need to do by the user. | 15. | Maintaining a local copy with the exact SVN data makes us more uncomfortable. The user has to copy the Project into the local folder with SVN data. |
| 16 | Auto copy of SVN updates: No need to provide any other code to copy the project from SVN to the local compiling folder. | 16. | Its not copying the data from the SVN directly. We need to write (In our case we wrote an ANT build file to download the latest copy of Project from SVN) something separate. |
| 17 | Running In background: If the server where we deployed the war is running then its okay for Hudson. | 17. | If we want to run it without console then we need to make it a separate ‘WINDOWS Service’ using any third party tool. |
| 18 | We can deploy the war file in any of the server we wanted. | 18. | Jetty server is using internally. |
| 19 | User authorization schemes. more configurable. | 19. | User authentication is there but no schemes at all. |
| 20 | Very Active mailing list. | 20. | From a long period people are using this. So it gives so many search results. But its mailing list is not that much active when compared with Hudson. |
Conclusion:
In my opinion Hudson much more better than Cruise Control. The time we will take to start to use Cruise control will be high when we compared with Hudson. The GUI which makes all the Configurations very very easy. The Ajax support makes the configuration more “Error Free”. Though Cruise control is using by a lot of people, when we looked into the features, mailing list, the fastness and support from Developers I think Hudson will be a good option.
Resources: lijinjoseji
