at my work we are presently looking for a automated build tool. We have googled quite a bit, but there are so many possibilities we are not sure which tool is the best option, to be honest.
We are not even sure there is one that fits our needs. It should have as many as possible from following features:
Integration with Subversion, meaning it should be able to do both updates and commits.
Diff tool or ability to integrate with one, and capability of auto-merging files (well, at least not the problematic ones).
Delphi build automation, using the command line compiler.
Integration with Oracle, meaning having the ability to run SQL scripts and compiling PL/SQL packages, functions, etc.
Sending of e-mails with build status (I guess this is something all of them have).
Additional functionalities would be welcome but are not needed at the moment. Anything in the line of getting at least points 1 and 2 would be great.
If anyone could point us to some particular tool we would be very grateful.
Thanks in advance and best regards
For my Delphi projects, I was using FinalBuilder (itself a Delphi app) way back when. I was always very happy with the product, and it worked very well.
In the meantime, they also launched a Server version of the build tool, so you can set up a full build server and have your code built there.
Another worthy contender back in those days used to be Visual Build - feature by feature the two almost match up, but the "feel" of the app, the ease of use, was with Finalbuilder, in my personal opinion.
I'm not sure if any of the two has direct and specific Oracle support, but at least Finalbuilder can run anything that can be run from the command line, so that should give you plenty of options, really.
I've been using CruiseControl.NET as a Continuous Integration server for our Delphi builds, which integrates quite nicely with NAnt as a build scripting language.
Forgetting about CC.NET, simply using NAnt would provide most/all of what you need, I think.
Combined with the extra NAnt-Contrib library of extra tasks, I have implemented everything you mention with the exception of the Oracle integration. However, you can easily invoke commandline stuff from within NAnt scripts, or write your own NAnt tasks using any .NET language.
NAnt has tasks for integrating with Subversion, or you can simply invoke the svn command line client.
I have invoked BeyondCompare as a diff tool from within my NAnt scripts, used NAnt to send customised HTML emails and execute Installshield builds, along with obviously executing the commmand line Delphi compiler and resource compiler.
NAnt is free and open-source, it's worth checking out.
Check also Automated Build Studio from AutomatedQA, it has many of the features you ask for.
We use FinalBuilder to handle requirements 1, 3, 4 and 5 and Beyond Compare to handle requirement 2 and have been very happy with both of these tools.
Apache Ant is open source and contains many tasks out of the box, and a very feature complete scripting and dependency management environment.
Subversion integration add-on: subclipse
SQL core task is included
Apply task can run any executable on any file pattern (like *.dpr)
Mail task included
Diff Patch task included
Also available: zip/unzip, tar/untar, xmlvalidate, xslt, ftp, telnet, scp, sshexec, cab, ...
I'm surprised no one has mentioned Hudson. Most build tools seem to target a specific language or platform. Hudson takes a different approach. It provides a plugin architecture so you can create a build server that fits your needs. The project itself is written in Java but is entirely self contained (with the exception that it depends on the JRE of course). It uses its own built-in web server to provide a user interface.
Embarcadero uses Hudson extensively and there are several great how to articles to get you started
http://christerblog.wordpress.com/2010/04/25/using-hudson-to-build-delphi-projects/
http://www.nickhodges.com/post/Getting-Hudson-set-up-to-compile-Delphi-Projects.aspx
And if you need commercial support the original author has started a company that provides a custom version as well as technical support.
Related
Can anyone advise what is the equivalent of hudson for c# application?
I used to use hudson as a build server for java performing auto deployment for java web and batch job application at scheduled timing and email notify technical team
I like to ask how can i do the same for c# application.
And is there any standard plugins like static code analysis tool in the build server which i can used to scan through the codes
In addition to the great tools mentioned by jamesj, TeamCity works pretty well too. I prefer it to CruiseControl, from a configuration usability perspective, and it is free given you stay within certain constraints.
If you've already invested in TFS as a source control, though, make sure you are getting your money's worth and use it for your builds and deployments too.
If you like Hudson, take a look at Jenkins. I've seen folks using it for .NET builds as well, though I haven't personally used it, and according to their page Jenkins used to be called Hudson, so it would probably be familiar to you.
TFS is great for continuous integration, but you can also use CruiseControl.NET with NAnt. Both of these should be able to run batch jobs, send emails and run automated deployments
StyleCop and FxCop both do static checking and both can be integrated into your build process.
I am 'relatively new' to unit-testing and TDD. Only more recently have I completed my first production application that has (at least in theory) 100% code coverage. I have done unit-testing in previous projects as well for some time, but not in true TDD fashion and with good code coverage. It had always been an after-thought. I feel I have a pretty good grasp on it now though.
I'm also trying to train the rest of the team on TDD and unit testing so that we can grow togeather and start moving forward with doing unit testing in all of our applications, and eventually progress to doing full TDD w/ automated builds & continous integration. I posted a thread here regarding my plan of attack / training agenda for comments & critisism.
One of the replies (in fact the highest voted) suggested I first setup infrastructure before I go forward with the training. Unfortunately I have no exposure to this, and googling on the topics is difficult because the pages for CruiseControl.NET / nAnt / etc do not really explain the 'why' we should set this up and the 'how' everything connects togeather.
We are a small shop (about 10 developers) and use almost exclusively microsoft technologies and do our development in VB.NET. We are looking to eventually start using C# but that's for another time. I've been using the MSTest project that comes with VS2008 for my unit tests, and I've been building my apps using Visual Studio, and deploying using MSI setup projects... We also (unfortunately) use VSS for our soure control - but that is also on the chopping block and I'd really like to get rid of it and use subversion.
I know that I need to use CruiseControl.NET for CI, and either nAnt or MSBuild for building the applications. And I probably need a build server to run all these builds. But I just can't find anything that 'connects' the dots and explains how they interact with eachother, what should be on your build server, when you should build with your build server (is it just for deployment builds, or even when you just want to compile the app you're developing after making a small change, on your local environment?). I'm also planning on axing MSTest as I've found it to be buggy and will use nUnit instead.
Can anyone perhaps illuminate this gap I have from 'knowing how to do TDD' to 'setting up the proper infrastructure so the whole team can do it and work togeather'? I do understand what continous integration is, but again, I'm not sure how a build server should be setup and how it connects with everything, and why we need one (e.g. the pitch to management).
thanks very much for your time.
What portion of finalbuilder do I need? It seems there's some overlap with final builder and teamcity. Finalbuilder server seems to be a CI server, so I'm guessing I don't need that. FinalBuilder seems to be a build server - but I thought TeamCity is also a build server... And Automise seems to be a visual windows automation tool, like some kind of development platform for winforms apps...
_I also don't see support for final builder in The Team City Supported Apps Diagram : _
Take a look at a webinar I did a few weeks ago - How To Start Unit Testing Successfully. In that webinar I've talked about tools and unit testing best practices and it was aimed at developers just like you who want to introduce unit testing in their organization.
First order of business you want to put a CI (Continuous Integration) process in place and for that you'll need three tools:
Source control
Build server
Build client/script
I hope you already have some form of source control in place so let's talk about the other two.
Build Server - checks the source control and when it changes (or some other condition met) runs a build script on some client (or same machine) there are several build server available I recommend JetBrain's TeamCity it's easy to install and use (great web interface) and is free for up to 20 developers (that's you).
Build Script - on your build client you want to run a build script that would build your solution and run your unit tests. TeamCity has some basic build & test capabilities but for more advanced options (build installer, documentation etc.) you'll need some script runner at work we use FinalBuilder - it's not free but has very good editor. If you're looking for a free alternative have a look at ANT or NANT - but be prepared to edit a lot of XML.
Other tools - Because an important part of successful unit testing is how easy it is to write and run tests on the developer's machines I suggest you check if there are better IDE's or external tools that would help the developers write & run their unit tests.
These questions are for TeamCity users only
1) Is it possible to configure TeamCity to extract build artifact information based on your own your regular expressions? This is exactly what Pulse does here
2) Does TeamCity integrate with any task/bug tracking tool? like JIRA?
3) This question is for people who run static code analyzer only. A tool like PC-Lint/Visual Lint can generate XML reports. Can TeamCity be configured to parse these artifacts and generate a build failure?
4) I'm currently evaluating TeamCity right now...there community forum doesnt seem to be very active. For those who pay for support, how is Jetbrains support? Is it good? Atlassian seems to be much better.
TeamCity allows to get build artifacts with a Ant-based pattern. You can specify multiple patterns and set target directory for each pattern. Read more at http://www.jetbrains.net/confluence/display/TCD4/Build+Artifact
There is an integration which allows to link RF-3432 to the Jira issue. More advanced integration may appear in the next release of TC. Read more at http://www.jetbrains.net/confluence/display/TCD4/Mapping+External+Links+in+Comments
Only with custom plugin. Or your build process can send a specific "echo" message which will change build status and description.
OK, I'm JetBrainer. May be we don't response immediately, but we strive to answer forum questions ASAP. Paid customers also have e-mail support.
Hope this helps,
KIR
Disclaimer: I don't work for JetBrains! But I've worked with Pulse and TeamCity in my current job.
Build Artifacts: Yes, TeamCity will export artifacts that remain after a build. You can add define ant-style wildcard patterns to match files (the default pattern matches any files left in the root build directory). These files can be seen from the project view against each individual build.
You can use special service commands in a build script to immediately export artifacts along the way too, I do this for a code complexity tool that generates xml files, for which I've also defined a custom graph.
Bug Tracking: I don't have experience with this, but KIR pointed out some alternatives.
XML Parsing: You can control this with ant. I included a third-party tool called andariel in my build that can run XPaths across xml documents, then used service messages to export the result (in this case a count of methods exceeding a complexity limit) to be displayed in a custom graph.
I believe you could also publish the artifacts, provide TeamCity with an XSL to render the XML, and create an additional tab in your build results to display it (however I have not done this)
Tech Support: I've found the community forums to be pretty good, most questions I've had answered within a day or two by both civilians and Jetbrains employees, and I was using the free 'Professional' version.
I can only imagine that email support will be just as good if not better!
I am a little confused about this question because my use of TeamCity, TC (and I guess the design principles of TC) is to allow the build script (and not TC) to remain the correspondent of build imperatives.
In other words, if you need TeamCity to do something cool, just add that cool stuff in your build script either using an existing task in your build system or write one yourself.
TeamCity supports NAnt, MSBuild, Ant and am sure, any other build platform you can install on on the buildagents.
The only integration I will want TC or any other CI platform to have is source control integration with my choice of SC. The rest of the integration should be controlled by my build script. That way, I only configure my TC once at the beginning of project for each project and then, don't touch it ever again. In contrast, the build can change per version.
So, the indirect answer to your question is Yes, theoretically, through the build script.
Hope this helps.
Setting up an integration server, I’m in doubt about the best approach regarding using multiple tasks to complete the build. Is the best way to set all in just one big-job or make small dependent ones?
You definitely want to break up the tasks. Here is a nice example of CruiseControl.NET configuration that has different targets (tasks) for each step. It also uses a common.build file which can be shared among projects with little customization.
http://code.google.com/p/dot-net-reference-app/source/browse/#svn/trunk
I use TeamCity with an nant build script. TeamCity makes it easy to setup the CI server part, and nant build script makes it easy to do a number of tasks as far as report generation is concerned.
Here is an article I wrote about using CI with CruiseControl.NET, it has a nant build script in the comments that can be re-used across projects:
Continuous Integration with CruiseControl
The approach I favour is the following setup (Actually assuming you are in a .NET project):
CruiseControl.NET.
NANT tasks for each individual step. Nant.Contrib for alternative CC templates.
NUnit to run unit tests.
NCover to perform code coverage.
FXCop for static analysis reports.
Subversion for source control.
CCTray or similar on all dev boxes to get notification of builds and failures etc.
On many projects you find that there are different levels of tests and activities which take place when someone does a checkin. Sometimes these can increase in time to the point where it can be a long time after a build before a dev can see if they have broken the build with a checkin.
What I do in these cases is create three builds (or maybe two):
A CI build is triggered by checkin and does a clean SVN Get, Build and runs lightweight tests. Ideally you can keep this down to minutes or less.
A more comprehensive build which could be hourly (if changes) which does the same as the CI but runs more comprehensive and time consuming tests.
An overnight build which does everything and also runs code coverage and static analysis of the assemblies and runs any deployment steps to build daily MSI packages etc.
The key thing about any CI system is that it needs to be organic and constantly being tweaked. There are some great extensions to CruiseControl.NET which log and chart build timings etc for the steps and let you do historical analysis and so allow you to continously tweak the builds to keep them snappy. It's something that managers find hard to accept that a build box will probably keep you busy for a fifth of your working time just to stop it grinding to a halt.
We use buildbot, with the build broken down into discrete steps. There is a balance to be found between having build steps be broken down with enough granularity and being a complete unit.
For example at my current position, we build the sub-pieces for each of our platforms (Mac, Linux, Windows) on their respective platforms. We then have a single step (with a few sub steps) that compiles them into the final version that will end up in the final distributions.
If something goes wrong in any of those steps it is pretty easy to diagnose.
My advice is to write the steps out on a whiteboard in as vague terms as you can and then base your steps on that. In my case that would be:
Build Plugin Pieces
Compile for Mac
Compile for PC
Compile for Linux
Make final Plugins
Run Plugin tests
Build intermediate IDE (We have to bootstrap building)
Build final IDE
Run IDE tests
I would definitely break down the jobs. Chances are you're likely to make changes in the builds, and it'll be easier to track down issues if you have smaller tasks instead of searching through one monolithic build.
You should be able to create one big job from the smaller pieces, anyways.
G'day,
As you're talking about integration testing my big (obvious) tip would be to make the test server built and configured as close as possible to the deployment environment as possible.
</thebloodyobvious> (-:
cheers,
Rob
Break your tasks up into discrete goal/operations, then use a higher-level script to tie them all together appropriately.
This makes your build process easier to understand for other people (you're documenting as you go so anyone on your team can pick it up, right?), as well as increasing the potential for re-use. It's likely you won't reuse the high-level scripts (although this could be possible if you have similar projects), but you can definitely reuse (even if it's copy/paste) the discrete operations rather easily.
Consider the example of getting the latest source from your repository. You'll want to group the tasks/operations for retrieving the code with some logging statements and reference the appropriate account information. This is the sort of thing that's very easy to reuse from one project to the next.
For my team's environment, we use NAnt since it provides a common scripting environment between dev machines (where we write/debug the scripts) and the CI server (since we just execute the same scripts in a clean environment). We use Jenkins to manage our builds, but at their core each project is just calling into the same NAnt scripts and then we manipulate the results (ie, archive the build output, flag failing tests etc).
I have a few Visual Studio Solutions/Projects that are being worked on in my company, which now require a scheme for automatic nightly builds. Such a scheme needs to be able to check the latest versions from SVN, build the solutions, create the appropriate downloadable files (including installers, documentation, etc.), send e-mails to the developers upon errors and all sorts of other nifty things. What tool, or tool-set, should I use for this?
I used to use FinalBuilder a few years ago and I liked that a lot but I'm not sure if they support such features as nightly-builds and email messages.
At my work we use CCNET, but with builds on check-in more than nightly - although it's easily configured for either or both.
You can very easily set up unit testing to run on every checkin as well, FXCop testing, and a slew of other products.
I would also advise checking out Team City as an option, because it has a free version, and the reporting and setup is reportedly much simpler (it does look nice to me). It does have a limit of somewhere around 20 team members/projects, before it hits a pay-for window.
That said, we started with CCNET, and have grown several products too large to look at Team City on the free version and are very happy with what we have.
Features that help with CCNET include:
XML based configuration - you can usually copy and paste most of what you need.
More or less you'll be able to plug your treesurgeon script in as your build script, and point CCNET at that as an executable task to run the compilation.
Lots of documentation and very easy to set up nunit, ncover, fxcop, etc.
Taskbar app that will let you know the status of your projects at any time, and it can also fire off an email or keep an RSS feed with the same information.
But I'd definitely go with running a CI build on every check-in - for the most part will run the unit tests before checking in, but let the CCNET server handle run any applications/assemblies that would have dependencies on the assembly we're checking in, and they get re-built, and re-tested on every checkin.
Given that CCNET is free free and takes very little time to set up - I'd highly recommend just going for it and seeing if it suits you, then expanding from there.
(There's another thread here where I posted pretty much the same/with a few alterations - but some of the other comments may help too! Automated Builds)
Edit to add: You can easily set up your own deployment scheme for CCNET, and there are a tonne of blog posts out there to assist, and email notifications can really be set up fairly granularly, either on all successes, all failures, when it changes from success to fail, etc. There's also built in RSS, and you could even set up your own notifiers for other systems.
FinalBuilder does support emailing and just executing FinalBuilder each night will give you nightly builds. You don't really need other software for that if you don't want to.
You could also use CCNet to trigger a build when needed and have it execute FinalBuilder for the build. You can then decide if FinalBuilder or CCNet should email.
Finally FinalBuilder has a Server version which is sorta like CCNet in that it is a continues integration tool using FinalBuilder. See http://www.finalbuilder.com/finalbuilder-server.aspx
Of course the biggest advantage of CCNet is that it is free and open source.
Although it costs, I highly recommend Visual Build. It works with MSBuild, and old tools like Visual Basic. It is scriptable, and can do everything from making installers to simple Continuous Integration.
We just started using Hudson here at the office.
Its free and open-source, it has a very user friendly UI. Plus there are tons of options and plugins available.
I was up and running in a matter of minutes after installing it. All the other devs here are loving it.
All in all, its a very elegant solution for Continuous Integration or Nightly Builds.
I've recently started using CruiseControl.NET (http://confluence.public.thoughtworks.org/display/CCNET/Welcome+to+CruiseControl.NET). It works reasonably well, although configuration could be easier. CruiseControl.NET is free and open source, and seems to integrate with most standard tools, although I've personally only used it with CVS, SVN, NUnit and MSBuild.
Luntbuild
Supports a wide variety of source control and build systems. Very customizable. Open Source. Setup takes some time, but it's not too horrible.
Buildbot is open source and very powerful too. You should take a look at it.
Cascade supports doing a build on every single change committed to the repository.
I would not recommend doing only nightly builds -- that's a pretty long window where a build break can slip in before it's reported.