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.
Related
Our current system is in .Net world and we are in the process of moving to FeF world (Angular) and we might keep the back end either in .net or change it to some flavor of JVM. We do not know about the server side yet but for sure, we will keep it as .Net for some time till we sort out the technology issues.
One thing I want to do during this time to do is build a CI system with language agnostic build tools. We use NAnt/MSBuild today. I would like to know as of now what are all active build tools out there, which can work with any language? I did find the following, but not sure how many are all active today. I am not trying to find which is best or not, all I want to know is the tool set and I will evaluate them based on our project requirements. I want to make sure I did not miss some build tool because I do not know the Java world.
Current list
Make
Rake
Gradle
BuildR
I did find this question but it is 5 years old.
Thanks
Interestingly if you look at the visual studio files in a text editor you will see that they are indeed build scripts. They are actually msbuild.
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
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
Microsoft has a lot of stuff in there, but I'm wondering what features of Visual Studio Team System people really like and really use.
I'm specifically thinking about Team System as opposed to plain old Visual Studio.
What makes it worth the price?
I use the Development version of VSTS2005 and evaluating 2008. My top picks:
Profiler
Coding guidelines -- rules enforcement part
My favorite
Profiler
Integrated Testing Environment: I know a lot of people prefer other test frameworks but having the integration is just sweet.
FxCop
Some of the best features come from adding Team Foundation Server:
Continuous integration builds can be set up to run unit tests on every build
Code coverage figures can be gathered based on the unit test run
Reports of build success, unit test success, code coverage %, etc. can be produced daily
Code check-in can mark a work item (bug report) fixed, or can start the workflow to do so
It not only gives the developers a better idea what's going on with their code, and of how to fix it (unit tests, code coverage, code analysis), it also gives Management an overall picture of the same, without having to come around and bug the developers individually.
I like the line-by-line blame, profiler (as mentioned), but more importantly, I like the reports it produces, such as defect rates over time.
However, even though there are plenty of features that I like, I certainly don't think it provides good value for money.
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.