Continuous Integration System for Delphi - delphi

Are there any CI-Systems for Delphi like Hudson for Java?
Does Hudson has any Delphi integrations?

We use Hudson :), which works just fine with Delphi.
Here's a complete setup for one of my projects:
<?xml version='1.0' encoding='UTF-8'?>
<project>
<actions/>
<description></description>
<keepDependencies>false</keepDependencies>
<properties/>
<scm class="hudson.scm.CVSSCM">
<cvsroot>:sspi:cvsonly:foo#bar:/baz</cvsroot>
<module>SIP</module>
<canUseUpdate>false</canUseUpdate>
<flatten>true</flatten>
<isTag>false</isTag>
<excludedRegions></excludedRegions>
</scm>
<canRoam>true</canRoam>
<disabled>false</disabled>
<triggers class="vector"/>
<builders>
<hudson.tasks.BatchFile>
<command>"C:\Program Files\Nant\bin\nant" -buildfile:etc\sip.build build-d7 test</command>
</hudson.tasks.BatchFile>
</builders>
<publishers>
<hudson.tasks.BuildTrigger>
<childProjects>quux, foozle, wibble</childProjects>
<threshold>
<name>SUCCESS</name>
<ordinal>0</ordinal>
<color>BLUE</color>
</threshold>
</hudson.tasks.BuildTrigger>
</publishers>
<buildWrappers/>
</project>
sip.build's delphi-7 target builds the project's test suite (DUnit's TextTestRunner) and so the output of the job is simply the count of failed/error tests thanks to:
var
R: TTestResult;
begin
R := TextTestRunner.RunRegisteredTests;
ExitCode := R.ErrorCount + R.FailureCount;
end;

FinalBuilder Server
now replaced with :
Continua CI

We use CruiseControl.NET, which works perfectly with Delphi.

It seems Embarcadero itself uses Hudson. See the comment from Nick Hodges, Development Manager at Embarcadero. http://blogs.embarcadero.com/nickhodges/2010/03/10/39369#comment-29952

Hudson is great, it is also available as MSI setup. Users of older Delphi versions (pre MSBuild), can create build scripts with the popular Apache Ant and NAnt build script environments. Simple command line (batch script) builds are possible too of course.
One of the highlights of this
installer is that it comes with a JRE,
to be fully self-contained. This is
because Windows users don't normally
know what to do with the *.war file,
and they generally don't like going to
the command prompt and running Java
command manually.
So it is easy to try without going through too many installers and command lines first.
And after installation make sure to visit the plug in page in the administration app, there are many extensions available which are also useful for Delphi developers. A plugin overview is online here.
Hudson tools for Delphi: there is also a Code Coverage tool for Delphi with Hudson support here.
TeamCity is another very nice CI system. It is a commercial product, but offers a free license for up to 20 users and 20 build configurations on 3 build agents.
Bamboo is a CI system for any language. It is available from Atlassian. Its price starts at $10 - this includes all features and unlimited users, but limited to 10 plans, running builds only on the server where it is installed. It can use Amazon Elastic Compute Cloud instances as remote agents.
Automated Build Studio from SmartBear. With Automated Build Studio Server, it introduced CI some time before FinalBuilder.

We use jenkins.
Jenkins has a RAD Studio plugin to integrate the compilation of Delphi projects into jobs. It's not mandatory to use it (plugin), we use command-line tools and MSBuild to compile the projects.
The project DUnItX (to create unit testing) integrates seamlessly with Jenkins.
Here you can find some articles about the integration of Jenkins and Delphi. Introduction, installation,... Are in Spanish but you can translate without problems and with included images and code are quite simple.
1- Integración continua con Delphi (GIT) (INTRODUCTION)
2- Integración continua con Delphi (Jenkins) – Instalación (INSTALLATION)
3- Integración continua con Delphi (Jenkins) – Primer proyecto (FIRST PROJECT)
4- Integración continua con Delphi (Jenkins) – Pipelines (USE OF PIPELINES)

Add our Parabuild to the list of tools to check out - it builds practically anything that can be built from the command line - that includes Delphi, and it provides integration with Perforce and other version control systems such as Git and Bazaar.

Hudson is simple to use, with some web-based assistants, as Delphi projects are built with MSBuild.
If you need more customization and 3rd party tools integration (integrate metrics tools for example) then CruiseControl.NET is the ideal solution.
Have a look to my CC.NET Dashboard page for DelphiCodeToDoc (and you can have a look to the configuration file also). I'm doing checkout + compilation of gui and command line version and unit test + unit test execution and report + ftp upload build delivery.

Just to throw my support for CruiseControl.NET, as Delphi 2007 and above are based around MSBuild, then there should be no problem with builds via CC.NET. There is a patch somewhere for DUNit, so that it outputs the results to an XML file, and this can then be integrated into the builds results charts.

errrm, can you define what you are actually looking for?
You use the phrase continuous integration, but do you just mean continuous build to make sure it compiles and likes, or do you actually mean continuous integration in the sense that you also run regression tests?
I would be curios as to how you do that (Auto-it?).
Not that it really matters too much, because the wonderful Hudson (which is decidedly not just for java) has numerous plug-ins, but will also allow you to execute a DOS batch script - any script that you care to write, to build, to test, to report results, etc.

Another option (although not free, $10 for limited # of users) is Atlassian Bamboo. And JetBrains TeamCity is another that is free (with limited # of users). I've tried both with Delphi 2009/2010, and they work quite well. Both allowed integration with Perforce among other SCM's.

We use Jenkins CI system with Owly CI tool as the build system and dependency handler.
Take a look on this tutorial
Initial setup takes less than 5 minutes

Related

Alternatives for QC

In my project we are using QC to execute our test cases(QTP), moving forward we would be eliminating QC (for cost reasons).
As far as I explored MSBuild & Jenkins, they would be suitable.
But MSBuild will trigger the execution when a new build pushed to the repository. Also it will automatically test on the latest build.
Is there any other CI tool available to execute test cases through QTP?
I will be executing automation once in a release. Also we install our application by manual since it requires lots of configuration.
Take a look at HP Application Automation Tools.
This plugin basically replaces the need for QC, and is developed by HP.
Create a Jenkins job using this plugin on the same Jenkins installation used to build your code, then you can configure your job to run your tests as soon the code is available (e.g. on a nightly basis).
See here for a helpful guide on how to implement a simple Jenkins job using this plugin.
They also host the code on Github, which is very useful if you need to change the behavior of the plugin to suit your needs.

TFS 2008/2010 vs Jenkins for Continuous Integration

Does anyone have specific experiences with using TFS 2008/2010 AND Jenkins for Continuous Integration (CI)? We are trying to decide which CI server to use. Our team works exclusively in Microsoft .NET/Visual Studio 2010/C#. We have the following requirements:
Automatically build our web project on every checkin.
Run unit tests with each build.
Automatically deploy green builds to development and/or test environments.
Provide pretty reports.
Provide build/deployment notifications via email.
I realize that installing a tool won't necessarily give us this functionality out-of-the-box and that we will have to integrate with other tools like MSBuild to achieve this.
I'm looking for specific features that Jenkins has that TFS 2008/2010 does not or vice versa. Also which is easier to maintain, use, etc.
I would highly recommend using Jenkins - it will do all of your requirements out of the box apart from possibly #3, but if you can script your deployments then it can do that as well.
Here are some links to help you get your builds up and running:
Blog about doing .NET builds in Jenkins
Jenkins Windows installers
Installing the Jenkins master and slaves as Windows services
Disclaimer: I have no experience with TFS, but I think open solutions are nearly always more flexible and extensible (and cheaper !) than proprietary products.
Late to this game, but I have used both TFS 2010 and Jenkins for CI. TFS 2010 has minimum set of CI tools in it. However, when you want to create a CI pipeline, it's a completely different story while Jenkins can easily create the pipeline.
If you are looking at only CI for one build either one should work. However, when it comes to the entire pipeline, Jenkins is way to go. With TFS it can be done, but Jenkins is better choice.
Here's quick bullet points:
TFS:
With a build definition you can compile, execute tests, return changeset/workitems, send an email when a build is broken
natural integration with visual studio
extremely hard to create CI pipeline. Requires custom handler and extensive workflow work. Not as intuitive as creating a build definition.
Because of the 3rd bullet, it's not easy to maintain/customize/scale CI pipeline
Jenkins:
Need to create a msbuild config file for CI, which is not much pain comparing to creating CI pipeline using TFS. However, TFS gives better/easier tool to create a build definition. however, it is not bad creating config file for msbuild for a project.
Creating a CI pipeline is very easy. Just chain them using upstream/downstream jenkins job trigger and passing an artifact from previous job.
Since Jenkins is very flexible, it is easy to create a jenkins plugin to meet your own needs and provide it to opensource community :)
In summary, if you need complete automated build, test, and deployment system go with Jenkins. If you just need only build and test, TFS might give you an edge over Jenkins.
If you're using Team 2010-2012, there is no reason whatsoever to bring in Jenkins. Team has all the features you listed, and the build process is ridiculously flexible.
Note that if you are stuck on Team 2008 or earlier, you should seriously look at Jenkins -- 2008 and earlier are quite primitive and inflexible compared to 2010 or later.

What toolchain would suit Java developers needing to build C#/F# projects with mono?

I am working with a team that develops a Java application using the following well-established toolchain for automated building, testing and continuous integration:
OS: Ubuntu
IDE: Eclipse
Build tools: Ant
Testing framework: JUnit
Source control: Subversion
CI server: Jenkins
A typical Jenkins job will grab the Java source from Subversion, and run Ant targets to build the code, run automated tests and create deployment artifacts.
We are now considering writing a .Net plugin for Windows clients to access our application's API from MS Excel. We will probably write it using either C# or F# - it's early days, and we haven't settled on a language yet, but F# seems as if it may offer some benefits in terms of being able to express API actions using a combinator-based DSL.
We would like to do as much of this work as possible on Linux, using Mono, and to use our existing CI infrastructure to build and test our software.
My first impression is that the toolchain will look something like this:
OS: Linux
IDE: Monodevelop / VIM (Eclipse support for Mono, and especially for F#, seems lacking)
Build Tool: NAnt
Testing framework: NUnit
Source control: Subversion
CI server: Jenkins, with NAnt plugin
Does anyone have any experience of developing with this kind of toolchain? The two questions I would like answered are:
What are the main pitfalls in this approach for developers used to the Java ecosystem?
Are there better alternatives to NAnt and NUnit for building and running automated tests, especially for F#?
Using F# with MonoDevelop on Linux seems like the way to go if you're developing cross-platform or server-side applications that can be developed on Linux (and occasionaly tested on Mac/Win).
However, I don't think that you'll be able to develop Excel plugin on Linux if you're targeting Windows users. You'll definitely need to run Excel on Windows and to test things, you'll probably also need to do (a part of) the development on Windows (I suppose the integration is the tricky bit - though you could develop & test some core functionality on Linux).
On Windows you can use free Visual Studio Shell with F#. The MonoDevelop integration for F# is (hopefuly) quite good, but Visual Studio gives you probably better experience and you'll need to use Windows for quite a few tasks anyway...
What are the main pitfalls in this approach for developers used to the Java ecosystem?
You are using a Linux operating system to develop an extension for Excel, which is primarily Windows. The Mono Platform is pretty excellent - but you could run into bugs - either with C# or F#. It's not as big of an issue as it was a few years ago, but worth considering. If you do decide to stick on the Mono / Linux platform - MonoDevelop is the way to go.
Are there better alternatives to NAnt and NUnit for building and running automated tests, especially for F#?
Take a look at FsUnit if you plan on going with F#. It has some nice syntax assertions, etc. It's complimentary to NUnit, so you won't be in uncharted waters.

How to efficiently do cross platform builds

I am setting up the build system for a team that produces APIs used on several platforms and architectures. There has been a lot of work already spent on setting up Ant to build all of the Java code, so I would prefer to stick with Ant if possible.
Where I am stumped is how to build the C++ software. Here are the platforms and languages I need to support:
Java - Linux - 32bit & 64bit: Ant
Java - Windows - 32bit & 64bit: Ant
C++ - Linux - 32bit & 64bit: Ant w/CppTasks (question #1)
C++ - Windows - 32bit: (question #2)
Note: C++ on Windows is MS Visual Studio C++ projects.
I think the answer to question #1 is CppTasks because that seems to be the standard way to build C++ from Ant.
For question #2, I could also use CppTasks, but the developers will be compiling in Visual Studio, so it seems beneficial to use their Visual Studio project for building, which means calling MSBuild from Ant.
Has anyone tried this before and has a good solution for building Java & C++ on both Linux and Windows?
Do you use a Continuous Build System like Jenkins?
With Jenkins, your builds can be automatically triggered by check in/commit, time of day, and/or on command. The great thing about Jenkins is that you can have it automatically build all of the various versions of your software.
For example, you'll probably need to run make on Linux C++ but use msbuild on Windows systems, and you'll need to trigger a build on a Linux machine and one for a Windows machine. Jenkins can be setup to do this automatically. When a commit happens, all your various builds on all of your systems can be triggered at once. Then, you can store the builds you need on Jenkins and have your users actually pull the type they need off the project they need.
There are so many ways this could be setup, but the easiest is to simply create four separate jobs (One for Java 32bit, Java 64bit, C++ Linux, and C++ Microsoft). You don't necessarily need a separate Microsoft Java build (at least in theory), but there's nothing stopping you.
You can have a single Jenkins server run "slave" jobs on other build systems, so you could have Jenkins live on the 64Bit Linux system, but use a 32bit Linux system as a slave to do the 32bit build, and call a Windows slave to do the Visual Basic build. That way, all of your jobs are located in a central place, but you can use the environments you want.
If you've never used a Continuous Build system, download Jenkins and play around with it. It's free and open source, and very, very easy to use. You can run it on any machine that has a JDK or JRE 1.6. If you download the Windows version, it even comes with the JRE already built in.
Your best bet is to use a continuous build system and allow it to handle the mess. By the way, there's also Bamboo, CruiseControl, and Hudson (which was split from Jenkins a few months ago)
TeamCity should fit the bill very well. It supports Ant and MSBuild natively and has a pretty good cross plartform story (written in Java but excellent integration with e.g. Win).
Dont see any benefit in wrapping you Win MSBuild-based builds in yet another build system.
The list for this looks a little bit different (in my opinion)
Java -Maven for all platforms
C++ - Maybe Maven as well (Check http://duns.github.com/maven-nar-plugin/).

Ant Tasks for Symbian

Are there any tools/ ant tasks that could be integrated into the ant build file to build Symbian applications? Similar to what we have for Android (AndroidAnt), BlackBerry (BB Ant Tools), .NET (Nant)
There isn't any officially supported stuff as far as I know, but (having done it myself) I know it is perfectly possible to build Symbian apps using Ant by simply calling the command line tools from ant commands.
If this is a precursor to automatically building symbian apps using a build server of some description, remember that Symbian builds have an annoying habit of polluting the build environment so you will need to invest some time into automated environment cleaning and environment setup.
This article is a good starting point: Continuous integration on Symbian OS
However, it doesn't cover the 'polluting the build environment' problem, which is an important one. In-house, we have fully automated Symbian builds using ANT and Cruisecontrol. We get around this problem by deleting/expanding the entire epoc32 tree with each build. This approach is fool-proof, but makes the builds very time consuming, which kills some of the benefits of continuous integration....
Actually Helium is the name of a Ant based build framework available through the Symbian foundation (http://developer.symbian.org/wiki/index.php/Helium).
It contains Ant build scripts and Symbian dedicated tasks (but not only, there are also general features...).
Developer.symbian.com and symbian.org links doesn't work anymore.
But mentioned continuous integration tutorial is available inside Symbianosunit package by Penrillian

Resources