cakebuild

VSTS vs NuGet vs CakeBuild – again!

Posted on by trailmax

I keep migrating my build scripts into CakeBuild system. And I keep running them on VSTS. Because mostly VSTS build system is awesome, it is free for small teams and has a lot of good stuff in it.

But working with NuGet on VSTS is for some reason a complete PITA. This time I had trouble with restoring NuGet packages:

'AutoMapper' already has a dependency defined for 'NETStandard.Library'.
An error occurred when executing task 'Restore-NuGet-Packages'.
Error: NuGet: Process returned an error (exit code 1).
System.Exception: Unexpected exit code 1 returned from tool Cake.exe

This is because Automapper is way ahead of times and VSTS uses older version of nuget.exe. If I run the same code locally, I don’t get this error. So I need to provide my own nuget.exe file and rely on that. This is how it is done in Cake script:

Task("Restore-NuGet-Packages")
    .Does(() =>
    {
        var settings = new NuGetRestoreSettings()
        {
            // VSTS has old version of Nuget.exe and Automapper restore fails because of that
            ToolPath = "./lib/nuget.exe",
            Verbosity = NuGetVerbosity.Detailed,
        };
        NuGetRestore(".\MySolution.sln", settings);
    });

Note the overriding ToolPath – this is how you can tell Cake to use the specific .exe file for the operation.

Database Integration Tests in Visual Studio Team Services and Cake Build

Posted on by trailmax

I’m a big fan of unit tests. But not everything can and should be unit tested. Also I do love CQRS architecture – it provides awesome separation of read and writes and isolates each read from the next read via query classes. Usually my queries are reading data from a database, though they can use any persistence i.e. files. About 90% of my queries are run against database with Entity Framework or with some micro ORM (currently I’m a fan of PetaPoco, though Dapper is also grand).

And no amount of stubs/mocks or isolating frameworks will help you with testing your database-access layer without actual database. To test your database-related code you need to have a database. Full stop, don’t even argue about this. If you say you can do unit-tests for your db-layer, I say your tests are worth nothing.

A while ago I’ve blogged about integration tests and that article seems to be quite popular – in top 10 by visitors in the last 2 years. So I decided to write an update.

Continue reading →

Cake Build vs VSTS

Posted on by trailmax

Cake Build system has an integration point with most build systems like Team City, AppVeyor, Bamboo, etc. But there is not much for Visual Studio Team Services (VSTS). There is a Cake Build Task that facilitates execution of Cake script on VSTS build agent, basically a wrapper around build.ps1.

But if you need to reach into any of the VSTS build process variables or call any of their API – you are on your own. And we are migrating our grand-project to be built on Cake and with VSTS.

And one of the pain points were NuGet feeds. We are consuming private nuget feed from VSTS and we are pushing a NuGet package into a private VSTS feed. Both of these actions require feed authentication. And VSTS authentication is painful.

Continue reading →

All Your Cake belong to… NOM-NOM-NOM

Posted on by trailmax

I’ve been converted to Cake. Not that I did not like a cake before, but this Cake is a build scripting system. The best thing about it – it is C# with all it’s might.

I’ve been using build servers for a long while, but never before I had a script that done completely in one go, one step. It has always been some snag that prevented this from happening.

For a long while I knew that it is a good practice to have all your build activities have scripted in one place. It is good for various reasons I’m not going to explain here. But every time I tried to implement this approach, there was something preventing me from getting the entire build process working from a single script, so every time I had to rely on different steps on a build server.

Bring on Cake Build

Gary Park a.k.a. @gep13 have been bragging about this system for a while and he is one of the main contributors on this project. Knowing Gary personally I decided to give this a go. And it worked magically for me!

All the factors that were preventing me implementing a build script as a single execution have been removed. Cake build script is basically a C# script with a lot of additions. And because it is C# – I know how to handle and work with it.

In addition to being C#, Cake also knows how to get and use NuGet feeds and anything you can do in your console application, you can do in Cake build script. For example if you wish you can get Newtonsoft.Json NuGet package for you build script and use JsonConvert.SerializeObject(obj); inside your build script. You add packages via preprocessor directives. This is very powerful.

Addins

There are a lot of addins that are available as NuGet packages. And they are getting downloaded on the execution – you don’t need to worry about them, Cake engine will take care of them – all you need to do is to add #addin nuget:?package=Cake.Foo.

Addins are so cool, I even built one myself for stuff that I used in my build scripts: Cake.SqlServer – small addin to aid working with SQL Server. It started as a refactoring exercise and then I decided to publish it as a nuget – it would be easier for me to share it between my scripts.

Conclusion

Cake is a cool build system for people who don’t want to learn XML or a special build scripting language. The only problem – it is not that widespread and sometimes finding an answer to problem is hard.