 Okay, that's good. So I guess I'll get started now because it's already 10 a.m. So thank you very much for showing up for my talk. I'll be talking about Hudson, which is the continuous integration engine I implemented in Java. So the idea of continuous integration just to recap is to, well, for having a program that looks for changes in your project constantly, and whenever it detects one, it starts to build a project and it produces the result, like the distribution, the file or the table and that sort of things. And then it publishes the result for other people to consume. And by doing so, it keeps track of how your project is used in other places. This is often useful when you have a graph of projects that are dependent on each other. And then because it's a server, so it exposes all those information to people, it brings the transparency to the projects. It's an open source project hosted on Java. We have many Java-based open source projects available. So this is a URL. And the code is implemented in Java, as the hosting site suggests. And one of the key points of Hudson is its extensive architecture. And so that enables the community to develop a lot of plugins that extend the capability of Hudson to various different areas. And that's been one of the big factor in success of Hudson. The project has been very active. According to all of the statistics sites for open source projects, it's supposed to have like a 116-person year of work of the code. And then the project itself is three years old if I look back to CVS committee history. I've been pulling directly 185 releases to date, and I'll talk more about this later. And I currently have maybe a bit more than 2,000 committers working on various different areas. Many work on plugins of their own. It's hosted in the same repository, some work on the core code. So it's a very active project, all in all. So again, to come back to what Hudson does, the idea of it is pretty simple that it first, you tell Hudson to listen to your source code management system changes by some means. One way to do that is to hook up to the notification emails because in that way you could avoid the cost like polling, which would be expensive. But you could also tell it to do the polling if that's the only way to configure. And by getting the notification from SCM it can trigger a build. Depending on how long your build takes, it basically takes the same amount of time. But at the end of the day you can capture the log of the build, the resulting files, the test reports, the code coverage reports, and that sort of things. And you can make it all available on Hudson's site. And by using those artifacts you could have other programs or other people downloading those artifacts or maybe browse the Javadoc or see the generated documentation and so on. Which is often handy when you're talking with someone else on the phone about some part of the system. It's much convenient to be able to see the same thing and then discuss about that. The other obviously more useful feature is to look at the test results or test failures when that happens. And then once you do those things you can then trigger notifications. So often when test failure happens it's useful to tell some human beings that there are regressions. So you can do that by using some means like instant messaging or the emails. So the reason why something like this is useful is because what I observed in my team during my day job, and I suspect that the many of those issues applies to you as well. Say you have a team of developers and one person makes a change in the code base in the morning and that actually contains some regression which happens occasionally. And then what happens is because often without the continuous integration you set up some kind of nightly bills and then the other teams like the testing team work off against these nightly bills. So in this setup, the earliest moment when the testing team, the SQE team can find an issue is to pick up the nightly bill of the Monday night. And that means the earliest moment the developer recognizes about this regression is going to be Tuesday morning. So we already wasted like 24 hours since the regression came into the code base until it was discovered. And then if it takes more cycles to fix it, for example, maybe the first attempt to fix this might fail actually. And then you're adding one more day to this life, I mean this round trip time. So all in all it does that a lot of time before the program gets recognized till the program gets fixed. And that's not good. By having something like Hudson which is constantly so the building and testing and making the results available almost as soon as someone makes a change you can see that change is causing a regression. And in that way you could fix adding that matter of hours not matter of days. And that improves the quality of the software. Another thing is the notification of the test result. The classic way of setting up this kind of continuous test execution is to have some kind of cron job that essentially just send out the test result regardless of the other failure in a no failure. So what that happens is maybe the first week the people are enthusiastic that now the final tests are running automatically and maybe they look at the test reports more carefully but the problem is when you bombard people with those emails they start to lose attention and then people won't stop looking at those emails. So quickly no one will look at those emails anymore so when the regression happens no one gets noticed and then it won't get discovered until it's too late. So having a server that sort of keeps track of what the history not just one time execution like cron it can do more sophisticated analysis about the test reports. So it could actually tell that there are five failures but these three of them are new, two have been failing for a long time. And so it could do things like calling attention to those three new bugs because all of our new regression is going to fail. So that's the kind of thing that Hudson does to improve your life. So the main theme of this or the main idea behind something like Hudson I hope by now is somewhat obvious. The first important part is to bring automation. There are lots of things that we developers do which can be automated and if you manage that computers do those works and we the people could get to work on more interesting things. So if you have enough time to waste on these mundane things so Hudson help you automate various things. The other thing is to reduce the time around time. I showed you an example where it takes days to get fixed to the regression and that's not good. Part of the reason that's not good is because it forces people to do context switching. If you can work on the same thing in short amount of time and get it done with people who are doing it in parallel and you have to come back every once in a day that's not very good. So by reducing time around time it managed to make people more productive. And having a server is also helpful in terms of bringing transparency to the project. This is sort of a bigger issue in a bigger team environment where you split the project into smaller pieces and then often what happens is you have to ask someone working in the project to learn anything like how to run a test or where to check out the source code or which branch they are working on. So when you don't have the information or when you have to ask someone else to get the information it makes you hard to participate in someone else's project which brings me to the last point which is to remove the people from the loop. When you're tying some people to the project and when it's not easy for them to move on to different parts of the project it creates problems. So the classic example might be like someone goes on to a vacation or someone goes on to a conference and give a talk about something like me and then people back in the office they need to do something let's say tag the workspace or post a new release or things like that and they can't do it because they don't know what to do and they can't do it because they don't know what to do and so on which is silly. And having a server again where you could see all those information available and then it helps you eliminate the people from the loop and then that allows people to smoothly move between components which is helpful. So all in all by doing these things Hudson tries to save people's time by using more machine time to use a lot more computers to throw at the program and then get to concentrate on things that matter like design and actually writing a code. And by pushing the jobs to the servers it manages to keep your workstation available. So often what happens is people run their tests on their own laptop and while the tests are running the laptops are not responsive enough so they can't do it. So by pushing those works to the server you can keep your workstation laptops available for interactive use like your IDE or editors. And so that also helps your productivity. So with that I wanted to show you a quick demo of how these things work. So I have a terminal that then I could launch Hudson like this, the Java that has some work. For those of you who are not very familiar with Java this is how you typically run the Java application but it's kind of unusual for web app to launch like this way. So it's this. So it's now running. And I... Yeah, so this is the main screen and you can see a few projects. This is my debug installation so you see some random projects in there. So the blue means things are the red if there is any red here that means something went wrong. The build failed for example. So this build failed for example. On the left hand side you can see the number of computers that are connected to this Hudson installation. The build and tests are often CPU and IO intensive so when you start to run lots of tests on the system you often need multiple computers like the cluster of the build machines that you can use to do a meaningful work. So this is the project I created for this demo. If I go to the configuration this is the kind of thing you need to tell Hudson to do the work. You need to tell Hudson where to check out the source code and once it's checked out I'm telling it to invoke. So this is an Ant-based project so I'm telling it to use this target. You can do other things like executing shell and so on but in this configuration it is useful. This tool specific configuration is useful to reduce the amount of typing that you have to do. They also provide better error checking. At the end of the build I'm telling it to our private unit test reports. One of the things I pay attention to is when they make mistakes and when they make mistakes they want to get back on track very quickly. So let's say if I make a typo like this it might be hard to see down below. It actually tries to guess what you meant by it. It didn't find test project X but it did find this much maybe that's what I meant and so on. So those are useful to get back on track. I learned a new way to improve the form validation. Once I configure the project then I could run I could schedule a build and because nothing else is building right now I could start building it right away. This one is a test project so it already finished building. It first checked out the project and then it ran the build and it recorded the result. I only had two tests so that is not very interesting. It runs too quickly. It's showing zero seconds. So this is actually a bit interesting. You can see the total number of tests so there are two tests and then there are zero failures but if you add a new test you'll see like the class one here if you see new regression you see like the class one here they are showing that the failure count is up. I found multiple tests. I can now see the graph of the test results in a more interesting project you see the test failure goes up and down and so on. You can see other things you can look at the files in the workspace and maybe look at all the source files and then I could go to the directory and so on. Looking at the file this is often useful when you're talking to other people and so on. So that's the kind of thing and since the time is short I have to cut the demo here and then back to this nice. So that's sort of some of the basics I have to get you some feeling of how it does it so the idea is you could create multiple projects in the Hudson and then you can have it individually configured and run it and so on. On top of those basic things what the Hudson provides for example is the permalinks to download the latest artifact. So this is often useful because not every automated systems like a test run or your QA cycles are hooked up to Hudson obviously so it's very important to be able to talk to Hudson from the other systems and one way to make that convenient is to have a URL that always resolves to the latest let's say the bundle so that the test cycle might be hooked with the Chrome and you can pick that up by doing W get on that permalink URL. It has RSS fees to look at the build results if coming back to the HTML user interface is not your way. It could also do email on the instant messenger notification with various protocols that people developed like IRC, Java and so on. And then the other thing that came in relatively recently is this ability to create a configuration matrix. This is particularly useful on testing where you'd have to say that I need to test this software on three different OSCs with two different databases and so on like in my day job one of the things I work on is JAX WSRI which is the web service toolkit for Java and that needs to be tested in three different OSCs that we support and then two different JDK versions that they behave differently. So the way it works is you tell the Hudson that this is the source location and this is the shell script to execute the test and so on but run this on all these configurations and it creates all the matrix and run the results. So in this report on the light what it's showing is it passed all the tests passed everywhere except in this particular configuration so there might be something interesting in here that's causing it. So I think it's important to see that having a large number of things to look at because it aggregates the results. The other thing that I spend a lot of effort in is the dependency tracking because well in a larger environment in larger team environment a big project is often decomposed into smaller pieces and then the lower level components sort of feed into the higher level components so what happens is the bug created into the library, lower level libraries, they only get discovered much later in the process. So when that happens it's often important to know which build of this library was used to produce this bug. Maybe some other related change has happened in the library since then which might have fixed the program and so on. So accurately knowing which build which contains all these changes is very useful. So Hudson does that by keeping track of MD5 checksum of the files as they come in and out of the Hudson systems. So by doing that it could always tell you, for example the test runs for the 5 in a tested the build of the 192 and so on. So that helps to simplify the bug tracking process. There are lots of plugins for integrating Hudson with other tools. The find bugs is a tool that's commonly in the Java world for integrating for doing static code analysis. So there's a plugin for that. A similar plugin is available for the copy paste detector in the PMD and so on. Because it talks to the source code management systems it knows who is making changes at what time and what changes are in it. So you can see that in this project that I took the poll senders has been single-handedly making most of the changes and occasionally you see more public eating and so on. That's often useful to see when was the last change and what has been changing to get an idea of what's going on. As I showed you earlier you can see the files in the workspace and download the files individually or you could also look at the checksum of the files. The manager always likes to see the charts so even personally I'm not sure how useful it is, it can do things like tracking how much time it's taking to build your project. So there are some random bits that I don't know what's going on in those places but generally speaking you can see that the project is building between 2 to 3 minutes depending on where it runs. So the outfit down here means the machine, the build machine that this build took place. The other thing that I did was the open search integration so if you come to the Hudson website the browser will tell you that you could register Hudson of the search engine and so what happens is you could then register you could then type in your project name or like the build number and come to the page directly or the other feature we got is build promotion support. This is another plugin and what it can do is well when you have a user integration system that producing lots and lots of builds it often overwhelms the downstream especially if they are not automated. So it's often convenient to be able to say just pick up let's say about one in five builds that are good some build that are actually good and test it as opposed to some random latest build which might contain some regressions. So the notion of promotion is the idea that once you do certain things, often testing and qualify that this build is good then you put some little marking like in this case a star and put some star and indicate that this build passed all these tests so it must be good. So Hudson could do these things automatically for you so in this screenshot what happened is I have like a four different test jobs that are hooked up to this build so every time a project builds these four test cycles gets triggered and if they all pass this build it's promoted and so this build was promoted 45 minutes after the build has happened so this is good to know how long you are taking to qualify a build because it helps to reduce the time the run cycles there and then the promotion has happened in 12 days before so once you promote a build you can also tell Hudson to do other things like you know send that we'll do some run some shell script like copy files or whatever and then a lot more supporting a distributed build so that you could upload your work to lots of machine in the cluster in my production system I have something like two dozen slaves hooked up to my Hudson system so that's often how many you need especially when you start to run a lot of tests. Source code management support is perhaps the area where the community support is the most helpful and I think the current list of support includes things like supporting material or the clear case for pros there are some work going on with Git and AcuraEv and so and tool integration as I mentioned with the fine varsity or the code coverage tools like ML and Covertura and then we have some IDE plugins with these three major IDEs and Hudson despite the fact that it started with the Java in mind it went beyond Java because people find use for it beyond Java and so for example for Ruby there are some people wrote this bridge or the connector I suppose it processes the test results and then another person will also write this spagging which lets you run the Ruby script as the build so if you're using those you could do that. The Python has a similar support in that space the .NET support is really more advanced because there are more people working on it and it has support for those tools that I personally don't use I can't comment on too much about that but those are useful if you're doing .NET development and beyond that because it can use at the sort of lowest level you can use Hudson as a way of like the glorified cron that can invoke any shell script so in that way you could integrate with any language so I didn't want to make this talk about the shell stock of Hudson so I wanted to spend a bit of time about how I implemented Hudson because there are some interesting design choices that I realize that are not very popular so one other thing is it produces a lot of data but so where does it persist those data and I actually don't use relational database for this because it turns out that one of the issues there is it complicates installation significantly when you try to support and I don't want to install all the major databases on my laptop to sort of debug all the issues that people are having with different database and because Hudson is the only essentially it's the only thing that's producing data and so there are not too much issue about the transaction and so on that the database is held and when the plugins come and go and they evolve independently from the core it's kind of hard to manage the extensively scheme evolution of the database and instead I chose to process everything in XML and much like the way the Java serialization work so the benefit of that is I managed to eliminate essentially almost all the glue codes it's sort of like it works like taking a snapshot of object and putting that in XML which is handy but because it's so transparent it's sort of easier for people especially the plugin level across to shoot yourself in the field because you sometimes don't realize there's a lot of duplication of making a slight changes which sort of affects the persistence structure so there are both side but I was generally speaking I'm happy with that and the other thing I do is the modeling of this so it's common to model the server in a stateless fashion because when you need to scale that's how you get the horizontal scalability but Hudson does it a bit differently so in memory of the model the natural representation of how the build server like Hudson behaves in memory as a tree of cast hierarchy so for example at the top level we have this Hudson object that roughly corresponds to the top of the page which is essentially a collection of projects and then each product has its configuration in it and they have a list of builds in it and so on so there's a little couple of lazy loading here and there essentially everything in the memory all the time but it turns out that the modern there are like 20 of memory in the modern computers so even if you accumulate like the tens of thousands of builds in your Hudson this turns out not to be a real program so what the point of doing this is so that once we have a tree I could actually mark that directly to the URL hierarchy so there's an underlying library that I wrote called stapler it sort of takes these three of objects and then map that automatically to URL but this helps to create a rather restful URL here you don't see like a long query parameter that's indicating what the thing is and it also internally it helps to route the HTTP request to the right object where the data is and let's say in application like PHP or a power the way people tend to write their application is well whenever a page is requested you look up all the query parameters and figure out which part of the data you're working on and then you make some changes and then you render the result which is a big unfortunate way of doing it so in this way because every object the incoming HTTP request gets invoked as an instance method on a particular object so I could always have all the data right available to me within the reach of a single object so this evaluation happens like a kind of a past expression language so when someone reports a URL like Hudson, Joe, Jack, speed or the 11 test report and what happens is it tries to look at the by using reflection it looks at the method and fields of the objects so example here it recognizes that the Hudson object has a get job method that takes a string so it tries to attempt these matches there and it returns another object so now it continues to evaluate the rest of the portion with this object so now I find we get build which takes an integer so that sounds like a match so I take that and then finally there's a get test report method that takes me to there so in this way just by having a single object model in memory I could sort of automatically generate the URL binding which is natural for people so when you see URLs like this it's sort of quite intuitive what it means so it helps people when they are passing around those references to other people or trying to guess so if you see this URL it's obvious if you wanted to see the test report for build 12 you kind of know what you need to do as opposed to having a long period URL and then the cluster eventually starts by either like the views which essentially render HTML and Hudson is using another Apache library called jelly and I don't know how many of us you know jelly but nowadays it's not a very popular choice but for a historical reason it could also use any other template language but Hudson has already accumulated too many views already so it's not practical to switch for us but if anyway you're thinking about using stapler for other things you can use other things like the velocity as a template language that's fine and you can either render HTML or you can do the the sublet like operations by defining a method called do something and then that also binds to URL so this is useful for making some actions before like rendering views but the difference between the sublet and this is that it's in both the right instance you already all the data that you have to work on is already available in your object as opposed to you grabbing things from elsewhere so the same applies to view what view often has to take a lot of data from the model object so just having them work like instance method where you can grab all the data from this object is very useful distributed computing is another area that we have to be out of your own idea that the build for the build server to scale you have to use a lot of machines so I needed a way to make this work nicely and I realized that the people are lazy at least I am so I didn't want to come up with a scheme where I asked people to deploy all the jars of the project in all the build machines in the consistent fashion because keeping them in sync would be very hard and even worse when people forget to keep them in sync they tend to get weird errors like this strange class compatibility related issues and so on so instead I opted for the scheme that works like RMI where the slaves download all the classes on demand so the slaves don't have to have anything they just get everything from the master including the program to execute so the way it works is on the master side the execution works in Java it's not very pretty to write a crawler so the syntax is a little more bulky but the example here is on the slave you want to execute this crawler that prints out the howler and then come back to the master and print out the another thing so when you execute this the whole crawler is here and sent to the slave the slave has a very thing computing server-like infrastructure that's capable of executing so it sends to you so once it's transferred it realizes that the class files that are necessary to deserialize these closures are not available in the slave so it makes an on-demand call to the master asking I need these class files so send them to me which sends back and then once that happens now it's capable of deserializing the closure so finally execute this closure on the slave side when it happens on the way back it sort of sends back the correct results serializes that and then send it back to the master and then the execution resumes on the master side so for people writing plugins which is the majority of Hudson developers this sort of makes it convenient to sort of come up with a convenient way of doing the distribution so this is not like the RPC style specific demoting where you have to identify functions that are front that are demotable and then you have to deploy it elsewhere and then there are other way other schools of sorts if I may for doing the demoting where you do define those contracts specifically so that you could board on the server and the client independently but this is very different from those ideas and in this scheme the demoting unit is rather anonymous you could create any closure and send it back to the slave and all the parameters are passed rather implicitly in the environment of the closure gets a lot more captured and then code gets delivered during the run time so no upfront deployment necessary that's part of the reason I opted for this is for the extensibility I guess that is well I'm sorry so the point of doing all these work of my own besides it's fun to do is for enabling extensibilities so the stapler allows plugins to seamlessly integrate into the URL hierarchy of Hudson which is much harder if you have a static sort of JSP like model and this deployment free distribution is also convenient for plugins because now people don't have to manage so many different things and the lack of database helps people like you know they're using XMA helps people come up with different ways of storing data without messing with the database schema which is often painful and so most of these objects that I showed you earlier like the jobs and SCMs and how to build a project and what's the trigger and so on they're quite extensible and the plugable so that's how people who clean to the Hudson and then they started writing their own SCM support or start writing their own instant messenger support and all the built in features like CVS and Subversion and all that they use the same mechanism so in that way I make sure that the extension points are used properly designed in a usable form and so that's a little insight into how I do Hudson and then the other thing is the last part of the talk is about what kind of things I emphasize in Hudson so it might be interesting to some folks so again one other thing I really tried to promote is to simplify installations because one way to put that is people lazy but another way to put that is people just don't have enough time to waste on crappy software like if it doesn't work in the first hour maybe they just might move on and never come back again so it's very important that the first expression of things are easy and nice and so in Hudson I tried really hard to simplify the installation so one of the end result is to be able to just download this file which is already a compressed form of the archive and then you can just run it right away and this is actually very uncommon for any other server application which at least require you to unzip the application and then maybe install a separate application container and maybe configure the database and then you can finally get going which is a lot of work and that's also a lot of steps where you can shoot yourself in the foot and make a mistake so this quite drastically simplifies that but the actually then it turns out that I can even simplify this that is I don't even have to ask you to download anything anymore thanks to the technology called Java Web Store so actually nowadays all you need to do to try Hudson is to come to your website and click a Java WebStat link and then what happens is if your browser is properly configured with Java which it's supposed to be and then it starts downloading this Hudson right there and then it executes things and then all your data is stored locally so even if you shut this down and come back to this later you still have all the data left intact so you really don't get the installation really never gets any easier than this or the other thing is the simplifying configuration people make silly mistakes like the typos and not knowing the right CVS root string and I don't want people to become diligently searching emails for the correct CVS root string or the right directory so one thing I put a lot of effort in Hudson is to help people to understand that Hudson correct people mistakes sort of automatically and so as I showed you earlier in the demo there is extensive on the fly form field validation it's not just about telling you that there is an error but it actually also tries to guess what the problem was and try to suggest to you what was the change so for example if you make a typo in the project name and so on or there are typical deployment errors in Hudson that you deploy to the sublet container that doesn't support the burden necessary for Hudson so it has an explicit check for those things and it gives you a nice a graceful error message as opposed to like the blow up and just choke so those are helpful in sort of helping smooth out the experience of people with Hudson but this is one area that still needs a lot of room still needs a lot of improvements every time I see my junior engineer using something at Hudson I learn I get to see how they are making mistakes and that feeds into my cycle so one of the thing I'd like to ask you is when you make some mistake don't blame yourself but blame your tools for not reporting the errors and tell us what we could do better the another thing is to use a barrier of entry to the project so I've been doing various free and open source steps of further development of different sizes and I realize that the typical project runs in a fairy to the strings and passion for example they emphasize on meritocracy meaning for you to become a committer you have to prove yourself for a substantial amount of time before you get to have any say on any sort of development then you have to prove yourself to be a committer or more and that's good for big projects where you have to chase away the potential contributors and filter them but for most of the projects that are small Hudson is no longer exactly a small project but for many of the projects the trade-off is wrong in my opinion so in Hudson I'm trying something else so instead of asking people to prove themselves before letting them commit taxes I almost give away commit taxes right away like if anyone asks it or even if anyone submits just a single patch but what happens is instead of instead of that I try to sort of split the code into plugins so that's where the architecture helps and then sort of emphasize the ownership of the plugin to individual people and that creates this sort of that sort of works very nicely with people's independent mentality that they get to own their part of the code and they can do anything with it and they don't have to talk to me about making any decisions there but I still sort of have this because they feel this entitlement to their parts they respect the other people's entitlement to the other part of the code so they don't just still talk to those people before making any changes to the other part of the code so I still get the same effect of avoiding random people committing randomly but without having the formalism of long commit taxes and then another benefit is when some people move on which do happen and then the ownership is gone but because people have a commit access they are technically capable so it makes it rather easier for having other people fill in the role of the people who left so it's a different trade-off of running an open source project but I find this working rather nicely for a small project there the main issue is soliciting more contributions and not about sort of screening people away so it's something that I thought I should mention the other thing is since I emphasize on people making plugins I spent a lot of effort creating an environment for plugin development so that is that is sort of emphasizing in terms of the Maven plugin and it does everything from initial skeleton plugin generation so that you can start with some simple the skeleton build script and all that from well to like the handle or the complicated compile time processing that this framework requires it also comes with debug support so just with a single command you can launch Hudson with your plugin and then have set up the dynamic reloading of things so that you can see your changes as you make them reloading or restarting your applications there are also release supports so when it gets time to release your plugin it posts the announcements automatically it uploads the private into the centrality post tree and so on the documentation is available and the website thanks to the help of the community and so all the effort actually sort of become fruitful so today I think I have something like 40 plugins available of different quality but they are good so I guess the takeaway is if you want to have something happen if you want to see something happen you need to make it easy enough so that people can do it just having stuff doable is not giving enough it really needs to be easy so that's one of the lessons that I learned another bit of experiment that I'm doing with Hudson is this frequent release cycles it's probably started with my frustration of my days over you get to release only like every once in six months maybe so in Hudson the current release model is every time I make maybe 4 to 6 RFEs or 5 to 6 I post a new release so that typically I must every once a day or every once a week on average so that adds up only to like 185 releases for the past three years and in a way it's a bit crazy but if I start thinking about the fact that the tests are all passing and I'm using it by myself and it seems to be working then if I make those fixes that people want to fix it obviously because it's causing issue for them so then I started thinking why shouldn't I just zip them so that they could pick up those bug fixes and then it creates a great turnaround time for bug fixes especially and the new features and people apparently love this so for example when you report a bug and get a fixing let's say three days it really sort of give you an incentive to report more issues so nowadays I get more more issues, more RFEs and bug reports and I can handle which is becoming an issue so the obvious downside of this is that people are not going to be upgrading every releases obviously so when there are so many releases people always attract like which version they should upgrade to so one of the things maybe I should have done is instead of trying to use this 1.x scheme so today the version is 1.185 I could have used like the 2.x scheme where you'd signify this amount of changes by using the second and third digit but that might be something else that might do later so in wrapping this up I encourage you to try Hudson Net if you haven't done so already it's very easy to get started and install and configure in the Sanctis Order WebUI in the form of validation it's primarily developed for Java but it's also great for non-Java so one of the things that I'm feeling is we tend to create this small silo for different languages in the open source community but it doesn't have to be that way so I wanted Hudson to be more language neutral in some way so I hope even if you're not using Java you might still I'd still encourage you to try Hudson and then the help is always appreciated there's lots of ideas about what you can do with Hudson but there are not enough people and conveniently, Sun is currently running this award program I think within the 6 months it's from now or so their contribution could actually be in a real money like I think it's up to tens of thousands of dollars actually unfortunately I'm not eligible but I'm sure you are there's a great chance of winning some real award if you contribute something or write talks or anything and then there's finally the website and the email address if you need to talk to me and with that I guess I'm done so yes I'll take any questions most wanted feature personally that's going to be a better maybe support because in my days more and more projects are moving to Maven and I needed more of it but yeah, yes so that's it I guess is there some way of auto updating if you're releasing every one to seven days or do you just have to keep scanning the website if there's a new release I'm sorry, I said okay, I didn't get the question so is there a way of doing an auto update for having Hudson check if a new version is out with bug fixes or yeah, it's one of the things I wanted to implement there's like a whole new idea if your Hudson installation is connected to the server and you get the update notifications for the Hudson or the plug-ins or just with the bottom mouse click it updates itself automatically for example that would be very handy and I can do other things like asking you to help me with the statistics and I'm always curious about which part of Hudson is used more and less because that helps me prioritize my work so there's a whole bunch of things I could do if I connect people's Hudson with the server but that's one of those many ideas that I have which I don't have time so if anyone is interested in contributing that's actually a great area could you give me three reasons why I should use a turn instead of say cruise control so your question is why should you use something like this instead of cruise control the question is there's loads of tools doing automation builds out there currently I'm using cruise control why should I switch to Hudson what would I get from the switch so the one of the benefits is it's much easier to configure because everything is on the web UI and any mistake you make is going to be corrected right there as opposed to using cruise control the other thing is it's a single server it's the most large number of projects so in my day job I have something like 400 jobs that different people hooked up the single system but only I need to babysit the whole Hudson installation whereas in cruise control if I understand correctly you have to have a single one server for one project and each project is on its own to set things up and in Hudson being aware of many projects it also allocates resources if this node is already building then it tries to move another build to someone else and so on so there's a lot of things you can do if the server is aware of multiple projects at the same time the dependency tracking is another one of those examples so I guess that's another reason I think the maybe the third reason is Hudson the web UI is a central part of it and then in any team environment I think having a server where you can come and see those things is essential whereas in cruise control it's more meant to be demoed and I feel that the UI is an afterthought so right so those are I guess the major reason but the cruise control is a good software I mean it's being used by many people but I don't want to discredit the people working on it but if you ask me why you should switch I guess those are the main reasons Hello I appreciate very much your philosophy of trying to destroy these walls between the different communities centered on different programming languages but I have one concern with this approach to distributing computing how suppose I have as a task to do some C compilation in my build form how will I go about packaging a C compilation task and sending it over so it's all nice to have this approach where we don't have to configure up front the build machines in the form but the question is how can you back and send over a C compilation task how do you say if I understand you correctly your question your question is how do you have tools necessary to perform your building all the slaves yes so yeah it doesn't sort of this is not like a cluster maintenance software so there's a different part of it a part of the maintaining Hudson cluster is definitely about maintaining a cluster you have to keep them up and running you have to keep those clocks in sync with the right set of tools available and so on so those works still needs to be done and there's not much I can do in Hudson to automate so for example in my data I have a small cell script a power script actually to deliver all the tools like JDKs and ant and C compilers to all the slaves in the right architecture because I have slaves with different architectures so those are done outside Hudson so if that's a question unfortunately it's still after you to do the other things okay thank you I have another question I would like to understand supposing that I have some policy like I want to make I don't know warning 274 fatal I want this warning to turn some task to red in my reports where do I configure that exactly so you have policy about to run no I have a policy that says some warnings are fatal I want to chase them out from the code where do I configure that where do I put the code that post process and detects this warning and then turns the result to a failure some of the plugins do that for example the violations plugin help you set up those arbitrary criteria you could say like well if you have 500 find bug issues consider the build to be failed because that's just too many and so on so the short answer is it depends on plugins so it's not like well yeah I guess the nature with it is essentially tools and domain dependence so that's how it works okay we got time for one more question if anyone has one one of the things I mean it's lovely as you said to be able multiple projects of one build machine but one of the things we've discovered is that you have to be fairly disciplined about resource usage say if you have a port that your tests use you have to make sure that none of your projects conflict because if you happen to be running two builds or you might have a port open so is there any Hudson as of now and it's unreasonable to expect it to do automatic dependency checking at that level yeah in fact there are some ports for example the TCP port example you mentioned is quite handy because we had the same issue some of the web app test requires for 8080 or some same tp some java mail testing requires for 25 so there's a plugin in Hudson that sort of allocates those things you could declare that this still requires these port numbers don't run this with other things that require the same port number the other thing Hudson could do is you can give me some like 5 3 tcp ports and then Hudson make sure that it doesn't allocate the same port to different jobs running at the same time so that's another way to do that and then there's another plugin for like controlling the other exclusiveness so it's called Lattice and Lux plugin that Stefan Connolly did and I haven't used it myself but as I understand it also does something similar so if you need to use the same database make sure that they don't collide with each other and so on so there are various ways to do it okay that wraps it up thank you very much thank you very much