Freitag, Oktober 29th, 2010 | by Daniel Siegl | Posted in .net Tools & Tips | 1 Comment »
We have a setup where a LAMP Server runs our WordPress Blog offsite.
Administration for obvious reasons doesn’t want designers to have direct access.
As of today we have a new Solution:
Designer Uploads the template to Subversion:

Teamcity picks up the changes from Subversion and runs a commandline that publishes the files to the LAMP Server

Originally we used this to publish AMUSE help to www.lieberlieber.com/amuse/help – but comes in handy here aswell.
Freitag, Oktober 8th, 2010 | by Daniel Siegl | Posted in .NET Framework, Teamcity | 1 Comment »
Inspired by a blog post from Roy Osherove – I wanted to be able to fire up additional build agents for peak times.
Yesterday Mario from Codeforce joined me to consult us on how to move Teamcity Agents into Amazon EC2. It took us two hours including lunch
After our session Mario made a nice blog post on the Topic:
How to run the Build Process in the Cloud with Teamcity and Amazon EC2 « All about Cloud Computing
Now we can build LieberLieber AMUSE even faster
Dienstag, Mai 25th, 2010 | by Nenad Steric | Posted in Buildserver, MSBuild, Programmierung Allgemein, delphi | 5 Comments »
If you want to set up Teamcity with Delphi you have to take care of several important issues :
You can run a build with the msbuild-runner, but the Delphi commandline-compiler needs additional Environment Variables :
- APPDATA : this is where EnvOptions.proj is saved, without it Delphi cannot compile anything, the Problem is that this is installed under the Config-Dir of the User who installed Delphi
Values can be :
German Win2003 – D2007 : C:\Dokumente und Einstellungen\<USER>\Anwendungsdaten\Borland\BDS\5.0
English Windows7 -D2010: C:\Users\<USER>\AppData\Roaming\CodeGear\BDS\7.0
etc.
- BDS – where Delphi is stored e.g. (for Delphi 2007) C:\Programme\CodeGear\RAD Studio\5.0
- BDSCOMMONDIR – e.g. (for Delphi 2007) C:\Dokumente und Einstellungen\All Users\Dokumente\RAD Studio\5.0
In Build file path you just need to add the <Project>.dproj File and your done if you just want to build the executable.
This alone already helped us to ensure that we always have at least all the source-files which are needed to compile the project, which wasn’t always the case before.
If you want Teamcity to also to run your Unit-tests then you have some extra work to do :
- Create a new Teamcity project with all the configuration from above e.g. <Project>-Test
- Then you need my adapted Console-Runner for DUnit, which emits the necessary infos for Teamcity.
Use this instead of the standard console-Runner from DUnit
e.g. change the Source of your Test-Exe Project to
Application.Initialize;
if IsConsole then
TeamCityTestRunner.RunRegisteredTests
else
GUITestRunner.RunRegisteredTests;
- Create a batch-file which calls the compiled Unit-test Exe and call it with Teamcity
and there you have it – a working integration of Delphi, DUnit and TeamCity.
Now if i only had a sure-fire way how to make all of the old GUI-centered Code testable so that i could switch to some Agile Practice like TDD …
TeamCityTestRunner
Dienstag, Januar 19th, 2010 | by Daniel Siegl | Posted in MSBuild | No Comments »
Just a found a tool that was missing in my Toolchain: Microsoft Build Sidekick from Attrice Corporation. Finally a nice and convenient tool to edit and debug MSBuild files that I use for my Teamcity work. It also supports the MSBuild Extension Pack.

Montag, Januar 18th, 2010 | by Daniel Siegl | Posted in Buildserver, Teamcity | 1 Comment »
This morning I found a pretty interesting overview provided by Roy on the tools you can use to get your builds maintainable:
The difference between continuous Integration tools and automated build tools
Personally I prefer the Teamcity and MSBuild Variation of Tools.
Freitag, Oktober 30th, 2009 | by Daniel Siegl | Posted in Programmierung Allgemein, Teamcity | No Comments »
Wir haben YouTrack jetzt schon einige Zeit als Issue Tracker im Test und werden es auch kaufen! Umso erfreulicher ist das YouTrack 1.0 released wurde. Besonders gefällt uns die einfache Integration mit Teamcity.
Montag, September 21st, 2009 | by Daniel Siegl | Posted in .NET Framework, Buildserver, MSBuild, Teamcity | No Comments »
If you choose to run Teamcity with a .sln you have an almost automatic integration into Teamcity that can be configured from the web interface.
For most stuff I end up needing a MsBuild Script to get all the Tasks done required for our Builds. If you choose MsBuild as a buildrunner in Teamcity you lose the nice GUI for configurating MsTest . So you need to run the tests by yourself with a simple target in an MsBuild script:
<Target Name=”MsTest”>
<Exec IgnoreExitCode=”true” Command=”"$(VS2008_Path)\mstest.exe" /testcontainer:BridgeTest.dll /resultsfile:BridgeTest.trx” />
<Message Text=”##teamcity[importData type='mstest' path='BridgeTest.trx']“/>
</Target>
The Trick is the Second Task which serves as a Service Message and tells Teamcity to Import the results from MsTest.
Other versions of running MsTest from MsBuild can be found in my previous post.
Mostly the same applies for Nunit Tests – yet you don’t need the Service Message because Teamcity can import Nunit reports from the gui.