We are working in a CI environment, with Enterprise Cruise running our builds. Developers all have CCTray installed locally to notify us if a build breaks.
CCTray has a menu option Volunteer to fix build that you can use to let your team know that you are fixing the build. However this doesn't work in our environment (reasons: Fix build not currently supported on projects monitored via HTTP).
So the question is - does anyone have a technique that they use in their team that allows someone to indicate that they are fixing a broken build?
For me, Continuous Integration is not only about tools, but also about practices. One of them is the responsibility. In others words, the one who breaks the build is also the one who will fix it!
Shooting "I take it guys" is my prefered. ( in addition of the responsability romaintaz describe )
We send an email to the Developer's mailing list to let everyone know you are taking ownership of the build break.
We're co-located, we all run cctray, and when the build breaks we have an audio alert (red alert from the Starship Enterprise). When it breaks we all shout "who broke the build"! Once we figure out who broke the build we harhass them until they tuck their tail between there legs, do that stupid embarassed laugh, and volunteer to fix the build.
It's worth noting that things that aren't monitored by the build and tests can change on a CI box. For example: maybe someone went onto the box and changed a permission. Then when the next checkin is made it looks like the person that made the checkin broke the build when really it was the person that made the manual change without telling anyone.
On the volunteer thing, tools can help but verbal face to face communication is still king.
The onus is usually on who broke the build with their checkin. That's often obvious, even with multiple checkins from different individuals. After that there's a bit of negotiation if the build remains broken. Not particularly scientific or rigorous, but it seems to work.
If the build brokes, then in CCtray there is an option for "Volunteer to fix the build".
And it tells automatically to all the developers who is fixing the build
Related
I've just installed SonarQube and it's understandably found a lot of technical debt that we want to eventually fix. However at the moment, I want to make sure that any new code checked in is evaluated and issues flagged in that.
I know I can mark issues as won't fix, but is there a way to flag issues that have arisen after a certain point in time and leave the existing technical debt as "Will fix later"?
I know ideally I'd like to halt development and fix everything right now, but I've only just got buy in for a CI server and some of my senior colleagues don't even see the point of unit tests, let alone ensuring code quality.
SonarQube focuses now on the Leak Period, i.e. problems introduced recently. This is handled through project versions, so you just need to update your string to start a new leak period and immediately differentiate old code from new.
Take a look at SonarQube itself on SonarQube.com. The highlighted "Leak Period" section on the right brings attention to problems that are new in this version.
My team uses the Radiator View plugin for Jenkins for fast feedback on the build status of a few different projects. One thing we discussed that would be helpful is if the SVN revision number were included in this view. After only a quick Google search, I haven't found a clear answer on whether this plugin is configurable or not; does anyone know if there's a straightforward way to add this information?
I dont think there are customizable figures there but what you can do is, pull down the source and get the revsion numbers for all the failing builds, you will have to write the code yourself, but from what I can see there is no way of doing this with the configuration options.
What you might want to try if you just need to get that information is the recent changes on the build page of the recently broken build.
Goodluck.
Can I ask why it would be helpful to have the svn revision number on display? As far as I understand it, a build radiator is supposed to 'radiate' meaningful information into the room. The svn number is fairly meaningless unless you can look up the number in the repository, in which case you could have just looked up the revision number on Jenkins anyway.
I'm just guessing, and do correct me if I'm wrong, but I suspect that your real desire is to have some way of quickly working out who might be responsible for a failing build. If this is the case, then processing check-in comments and displaying pictures of the users involved is a far more effective way of getting developers to react to failing builds. I've experienced this first hand at my company.
With this in mind, I have developed a standalone build radiator webapp that talks to Jenkins over its REST API. CI-Eye is trivial to set up, and will probably give you better results in the workplace than the Radiator View plug-in. Give it a try, and let me know what you think -- I'm quite actively improving it, and welcome any feedback.
CI-Eye is free and open source -- see the CI-Eye wiki for more details.
Hudson is a great tool, and the emails it sends about failing builds are a great help. However, it can only do this if Hudson itself is in a working condition. It is able to report problems with its own executors like low disk space, unsynced clocks etc. on the web interface, just as it reports build problems, but I couldn't find an option to send email alerts about these. Yet it would be so useful, and seems so logical that this feature should be there.
Am I looking at the wrong place to fix this? Is there another solution to learn about problems with executors without having to poll the web interface every now and then? Am I missing something?
Did you check all of the plugins?
Did you ask on the http://wiki.hudson-ci.org/display/HUDSON/Mailing%20List ?
Personally, much as I love Stack Overflow, I only use it after I have exhausted more dedicated possilities such aa a dedicated foru, mailing lists, emailing the author(s)/maintainer(s) ..
Sorry.
Btw, I have been using Hudson for years and and say that there is - IMO _ mothing better.
As a last resort, maybe you can hack the source code? This sounds like a reasonable feature so I am sure that your code would be slipstreamed into the main build; failiing that, package it as a plug-in
Have a look at the remote API from Hudson. http://wiki.hudson-ci.org/display/HUDSON/Remote+access+API
You can use it to query the statuses you want programatically. You can also file your request as a hudson issue or document it with the The new emailer plugin
OK, so we all know the daily build is the heart beat of a project, but whats the single best way of automating it?
We have perl scripts wrapping our pipeline which includes ClearCase, VS2005 (C++), Intel FORTRAN, Inno setup. We use cron jobs on UNIX to schedule the build, and host a simple Apache web server to view and monitor the build. All in all its rather complex, I would like to know whats the best off the shelf solution that people use?
And yes I did say FORTRAN no escaping it sometimes, it works, no point doing a huge re-implementation project for some tried and tested FEA code that just works.
A new one to me that I've heard is quite slick is hudson - also with MSBuild support.
We're in the process of implementing CC.Net. So far it seems like it would fit your model pretty well.
Out of the box it offers automated building, results tracking and notification. I'm not sure how detailed the build-in-progress monitoring is though.
There are many tools that specifically handle this:
Cruise Control
Hudson
Continuum
The tools have out of the box support for the most common build types. They all also support some sort of "run this script" type build process.
In the end you should use the nicer build tools (MSBuild, Ant, Maven, Make, ...) where you can and fill the gaps for the odder tools with custom scripts. The automated build can just invoke these in the right order.
Here is the best resource we found to help us pick a Continuous Integration tool. We have been evaluating 5 or 6 tools on this page.
http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix
We use TeamCity - but then its a simple C#/Java development - maybe your pipeline can done via scripts it can drive?
I have had success using Visual Build Pro.
CC.NET is very powerful. Used it and was really happy about it. Even the status icon in the systray. It's a small detail, but it gives you a good overview of the project's "health". You immediately feel motivated to fix the tests when you see it red.
Now we use a self-baked series of scripts. Since we write Python, compilation is non-existant, so the only problem is running the tests.
If you're working with Visual Studio, be sure to check out Team Foundation Build to see if it will suit your situation.
It looks like Buck Hodges' blog post on the VS 2008 version is a good resource, too.
I know this is a really old question, but it's still coming up in searches, so someone should mention Jenkins - the open source continuation of Hudson.
From the Jenkins wiki:
Among those things, current Jenkins focuses on the following two jobs:
Building/testing software projects continuously, just like CruiseControl or DamageControl. In a nutshell, Jenkins provides an easy-to-use so-called continuous integration system, making it easier for developers to integrate changes to the project, and making it easier for users to obtain a fresh build. The automated, continuous build increases the productivity.
Monitoring executions of externally-run jobs, such as cron jobs and procmail jobs, even those that are run on a remote machine. For example, with cron, all you receive is regular e-mails that capture the output, and it is up to you to look at them diligently and notice when it broke. Jenkins keeps those outputs and makes it easy for you to notice when something is wrong.
It was originally built with Java in mind, so it integrates well with lots of other Java tools, but you can use it with any language, including all those mentioned by the OP.
I use cruisecontrol.rb for CI and FogBugz for bug tracking, but the more general the answers, the better.
First is the technical problem: is there an API for FogBugz? Are there good tutorials, or better yet, pre-written code?
Second is the procedural problem: what, exactly, should the CI put in the bug tracker when the build breaks? Perhaps:
Title: "#{last committer} broke the build!"
Body: "#{ error traces }"
I suppose this presupposes the answer to this question: should I even put CI breaks into my bug tracking?
At my company we've recently adopted the (commercial) Atlassian stack - including JIRA for issue tracking and Bamboo for builds. Much like the Microsoft world (I'm guessing - we're a Java shop), if you get all your products from a single vendor you get the bonus of tight integration.
For an example of how they've done interoperability, view their interoperability page.
Enough shilling. Generally speaking, I can summarize their general approach as:
Create issues in your bug tracker (ex: issue key of PROJ-123).
When you commit code, add "PROJ-123" to your commit comment to indicate what bug this code change fixes.
When your CI server checks out the code, scan the commit comments of the diffs. Record any strings matching the regex of your issue keys.
When the build completes, generate a report of what issue keys were found.
Specifically to your second problem:
Your CI doesn't doesn't have to put anything into your bug tracker. Bamboo doesn't put anything into JIRA. Instead, the Atlassian folks have provided a plugin to JIRA that will make a remote api call into Bamboo, asking the question "Bamboo, to what builds am I (a JIRA issue) related?". This is probably best explained with a screenshot.
All the CI setups I've worked with send an email (to a list), but if you did want—especially if your team uses FogBugz much as a todo system—you could just open a case in FogBugz 6. It has an API that lets you open cases. For that matter, you could just configure it to send the email to your FogBugz' email submission address, but the API might let you do more, like assign the case to the last committer.
Brian's answer suggests to me, if your CI finds a failure in a commit that had a case number, you might even just reopen the existing case. Like codifying a case field for every little thing, though, there's a point where the CI automation could be "too smart," get it wrong, and just be annoying. Opening a new case could be plenty.
And thanks: this makes me wonder if I should try integrating our Chimps setup with our FogBugz!
CC comes with a utility that warns you when builds fail, it probably isn't worth logging the failing build in FogBugz - you don't need to track issues that are immediately resolved (as most broken builds will be)
To go the other way round (FogBugz showing checkins that fixed the issue) you need a web based repository browser - FogBugz is easy to configure so that it shows the right changes.