My team has a goal to minimize the amount of time that our build is broken.
We use CruiseControl.NET for continuous integration. What I'd like to find out is how best to approach answering the following question:
"In the last {timespan}, how much time has {project-name} spent in a broken status?"
For example:
"Over the last 1 month, how much time has our project spent in a broken status?"
Are there any advanced features of CruiseControl.NET that would facilitate making this information available in some type of a report or somewhere in the dashboard?
Alternatively, how would you approach parsing the xml artifact files to glean this info?
you can use the statistics publisher,
http://www.cruisecontrolnet.org/projects/ccnet/wiki/Statistics_Publisher
and you can display them via project statistics plugin
I see at least two ways to approach this:
You write an external tool which parses CC.NET's XML log files for a project (stored in buildlogs subdirectory by default), calculates statistics and writes a HTML report. This is probably easier to do, but it won't be directly integrated with CC.NET.
You write a CC.NET plug-in to do this. You'll need to do a bit of investigating in this case. My guess the starting point would be to look at the source code of some existing plug-in.
Here are some links about CCNET plugins:
http://www.cruisecontrolnet.org/projects/ccnet/wiki/DevInfo_MakingPlugins
BrekiLabeller - my own plug-in, useful if you want to see how a plug-in can be implemented.
Having had a very quick look at the CC docs, I imagine if you were writing your own Cruise control dashboard, you could consume the RSS feed of build results, parse in all the date times and success/failure states up to your threshold, then sum up the totals.
As for displaying it in a dashboard, I think Cruise Control has a plugin architecture which might help http://cruisecontrol.sourceforge.net/main/plugins.html
So my eventual solution wasn't ideal, but it was easy to do and it works:
I had CC.NET send build emails to an email address (we'll call it build_emails#build_statistics.com). Then I use a ruby script to get the emails via imap and process them to determine our build failure time.
I didn't go the route of directly parsing the xml because I would have had to parse every xml file in the timeframe to build up a timeline and then go over the timeline to make my calculations. It just seemed too complicated to get a simple statistic like this.
I like cc.net, but in this case TeamCity just does this for you. It has lots of other great statistics too. It's free for less than 20 projects.
Related
Is there a way to make Jenkins accept and graph test results that aren't binary passes/fails?
I'm writing a performance test for an Open Source project I contribute to. After each successful build, I would like Jenkins to run a bash script I've written, then report as the test result a value I compute during the test. The value would be on the order of 10k, if that matters. The idea is to allow devs to view the historical performance of the codebase, as well as how their commits changed it.
I'm new to Jenkins, but I've Googled pretty hard and found nothing relevant. Links are appreciated, even if you don't have a full answer.
The Plot plugin should be able to do what you need; you can store the test results in csv format and then graph them across all builds.
Is there any way to generate the good error report from Cruise Control?
I like to get the following things in that report.
The line number of File that break the build
The name of developer who commited that file. (It should not be related to last person who committed because the build might be broken earlier before last person check-in. )
Thanks.
this should be doable with a bit of xsl parsing alone :-)
Needed steps :
Create the xsl file (blame.xsl for instance)
this xsl should look at the <modifications/> node and the <msbuild/> node to get the data.
Define a new xslReportBuildPlugin in your webdashboard.config pointing to the
new xsl file. Something in the likes of :
<xslReportBuildPlugin description="Blame"
actionName="BlameBuildReport" xslFileName="xsl\blame.xsl"/>
do an iisreset to activate it (just to be sure) and clear your browser cache
now you should see a Blame in every build report :-)
Custom report creation information
A custom xsl modification to bring the error info up to the top of the file - this would be helpful in applying the blame
Then if you add in thesteps from Williams' answer you'd have blame information.
You do already have the file/line number. CruiseControl.NET provides the detailed MSBuild report, which is nothing but the usual compiler output.
This would be only possible with an extension that is specific your the Version Control System. You would have to write such an extension by yourself (but I doubt that it's worth the effort...).
HTH.
I've just implemented build and deploy process which consists of java files, ant script and cmd files. In the process, a release manager will have to check out source, hit the build.cmd button and then carry a zip file over to a server.
I am wondering if it is worthwhile to make a GUI for it? So that the release manager does not need to check out source manually for example?
How do I start? I have quite limited knowledge of javax, but I very much like to learn.
Thanks,
Sarah
This sounds like something that could be handled by Hudson. It can check out source, run Ant scripts, etc., saving you the trouble of maintaining a GUI. I'd give that a shot before rolling your own.
I have helped develop the build process at my current company. The way we currently do it is with a script file. It checks out the latest code from the stable branch of our repository, performs some steps to get some data from a database (such as static SQL data that needs to be loaded at deployment), then compresses everything. The file is then distributed to our production servers and then the setup routine is executed. Everything is automatic and the script is written in Python. Python is great for these types of things because of the sheer number of libraries it has to help the developer.
Perhaps it may be useful to build a GUI for your deployment procedure -- typically this would be useful if the deployment requires user interaction to make decisions, such as "Which server shall I deploy to?", etc. But, if it's just a matter of doing things automatically, then a script file's the way to go. Choose your favourite language and dive in -- I of course recommend Python.
If you'd like to learn how to make a simple GUI in Java (since that seems to be what your company is familiar with), you should check out the stuff at this site:
http://java.sun.com/docs/books/tutorial/uiswing/index.html
I learned everything I know about Java from that site. The section on GUI programming is great.
Best of luck!
Shad
As a follow up to one of my previous posts 'Using Version Control for Home Development', I am now asking about opinions as regards using a Build Server for a pet project.
Lately I have been reading about this 'Build Servers' concept, and I have looked at applications such as Maven and CruiseControl.Net.
And thus I ask, how feasible is it to use something like CruiseControl.Net for my home pet projects?
Reason I ask is that I think that these Build Servers are mainly aimed for team projects...but then again, I'm still very new to this Automated Build process.
Keep in mind that most of the time, these pet projects are only handled by one man, not a team.
So should I look more into this concept for the sake of using at home, or should I just get some practice on it for experience's sake?
[EDIT]
Although I thank you all for your answers as regards alternatives to CC.Net and such, no one has yet really tackled the issue of whether it is feasible or not to implement a Build System for Home Development ?
It is completely feasible to implement a build server for your home projects. I've implemented CC.Net for my home projects myself and it is pretty easy to do so, even for the first time. I would say the learning curve (depending on your experience) is less than a day to get your first project up and building, though there is always the longer tail on that curve as you dig into some of the more interesting details.
The question to me is more one of the motivation for continuous integration on these projects. If you are using "Home Project" synonomous with "Throw-away Project", there probably isn't much point in going to the trouble of CI unless you are using it specifically as a CI learning excercise.
However, assuming these are not throw-away projects you are talking about, I've found (in addition to the more obvious benefits of automation) that implementing CI helps reduce the overhead involved in coming back to a project you've walked away from for some period of time. Of course, unit tests are the most valuable asset in this regard, but the combination of unit tests with an automated build/deployment process really allows you to focus on the new and changed requirements when you come back to a project after having set it down for a while.
Additionally, as mghie points out in the comments to this answer, "CI will give even greater benefit for home projects if they build upon each other, so changes in one project could cause the build to break in others."
My advice, just do it once so you have a clearer picture of what is involved and the benefits you might reap and drawbacks you might incur. Then make the decision for yourself as to whether or not it is worth continuing to do. Like I said, the learning curve is reasonably low so the investment you will have to make in just giving it a try shouldn't be the reason not to.
Nutshell: Feasible - Yes, Desirable for home projects - Quite Possibly, Worth further investigation - Definitely, Investment - Relatively low
As an alternative to CC.Net, I recommend you to give a look to TeamCity, is really easy to setup and get it up and running.
Related question:
Best Continuous Integration Setup for a solo developer (.NET)
i installed CC.net months ago it took me a whole night to configure it and create the xml configurations and i have no regrets about it, it smoothly integrates with SVN, Nunit, Nant or Msbuild. you should try it only if it is to gain experience
Take a look at Hudson its very easy. You need to just deploy in Tomcat or any other servlet you use container. Once up every configuration can be done using browser. Hudson supports maven, ant etc and supports all the major SCMs. I have been using hudson for the past one year and not faced any trouble.
CC.NET is very feasible, in fact with the free cost and wide ranging supported actions. Not to mention the fact that since you can get the source code you can modify it to you needs I could not imagine anything better. I read the other compliants about how difficult it is to set up, but to be honest I had my first simple TFS/VS2005 project up within an hour. Just remember if you run into any issues or snags CC.NET has a pretty active google groups for Users and Devs who would be willing to help you through any gotchas.
I love CC.NET and I'm a big fan of CI, but I have to ask: with only one developer on the project, what integration scenarios exist? Wouldn't you just build the entire project in Visual Studio, negating the need for CI?
I would agree that CC.NET is a great option for local/home development. I wanted to add that it does not require an SCM tool in order to make it work. There is a file system watcher plugin that will just monitor for a file change. That way you don't have to have a check-in in order for it to execute. Also you don't have to wait for the CI cycle to complete, it's much like having F6 run everytime except for the IDE doesn't use all it's resources, you can keep coding away. If it breaks, you can choose to investigate or just ignore. There is no one way to do CI.
If you do create unit tests, having that constantly execute against your code on every save certainly has some advantages in early problems. Using CCTray allows you to see it, but not be intruded upon. My 2 cents.
Finally, setting it up the first time can be a little tough, but you can tweak out a Visual Studio C# template or whatever you desire to automatically configure your CI setup with the least amount of information required by the user.
What is the initial cost of setting up CruiseControl?
The key point here is not the time you have to invest in setting up CruiseControl. You can do this in an hour or so. The question is weather do you have a code repository (SVN, TFS) and a build script ready (something - MSBuild script or so - that will clean, rebuild, test and deploy your app). If not you will have to invest some time in that - depending on how complicated your project is - but surely it will take a lot more time than setting up a CruiseControl server.
Not more than two to three hours worth if you're new to it. The first time I used it I had something that checked out the latest version from subversion, compiled it using MSBuild and then upload it in less than that time.
I'd recommend Hudson over CruiseControl any day of the week. I can't think of anything CruiseControl can do which Hudson doesn't do (better). Especially the web-based frontend is far superior. You can run Hudson directly on your machine (using JNLP) and have your project setup in minutes.
It takes a little while to get it up and running - but you can get a solution to build using the task to build you .sln file in less than a day if you're a complete newbie on the subject.
It gets a little more complicated when you add unit testing in various frameworks, costumizing the dashboard, labelling your builds etc but it's a matter of days, not weeks to get anything up and running.
Software - free.
Hardware - cost depends. If you only want to run nightly it can probably share server space with something else. We use a dedicated server with builds every 15 mins.
Set up time - Once learnt you're looking at a few hours to set up a new server. If you're new to CC allow a day or two.
If you've never used an integration server before you're going to have a learning curve for the entire team - allow a few weeks.
We've recently moved to a new server and we set up a fresh installation - it took a few hours. That's for four projects, two different source control providers, and includes custom tasks like reporting and building help files.
I'd recoccomend a dedicated machine for cruise control, it doesn't have to be amazingly powerful but bear in mind it had to be able to compile your code.
We used an old developer's machine, which was put aside after an upgrade.
As far as the cost in time a day should have you up and running.
How do you define 'cost'? It's free to download so there's no monetary cost.
In terms of time it should take between 1/2 - 1 day, depending on how complicated your configuration is.
If you have a simple project with no dependencies then a couple of hours. If you are actually doing 'integration' of many projects with many dependencies then several weeks and possibly code changes. IMHO CC.Net doesn't scale well to large numbers of projects...
You should be able to set it up in about 3 hours and it's totally free.
Still you can spend money on external tools like Simian etc, but that's totally optional. Setting up CCnet really is a matter of going through the configuration documentation and that's it.
I blogged about my experiences with CCnet before: http://www.tigraine.at/2008/10/08/another-take-on-contiuous-integration/
Jay Flowers runs a project called CI Factory which enables you to put together a CruiseControl.NET installation with optional modules in no time at all.
http://jayflowers.com/joomla/
Also, you might wish to listen to the .NET rocks podcast interview with him:
http://www.dnrtv.com/default.aspx?showID=64