TeamCity

Azure Mobile Service deployment with Team City part 7. Deployment to Test environment

Fri, 04 Sep 2015 06:05:21 GMT

The last step in these series of posts is deploying from TeamCity to a test environment.

We have already created the script which will do the deployment so we need only to create the TeamCity configuration.

Although we can call the script which will do the deployment directly from TeamCity I prefer to have another separate script which at its turn will call the deployment script. In this way we test it locally and if we need to add more functionality we don't have to change the TeamCity configuration. For this purpose we create run-delpoy.ps1 script which will have the same set of parameters as deploy-package.ps1. The script takes input parameters and calls the deploy-package.ps1 script.

Make sure you have created a test Azure Mobile Service instance.

Now let’s configure TeamCity. On the User Management settings page (Administration > User Management) and click Create build configuration.

I will name it Mobile Service Test Deploy and click Create button.

In the next step – Version Control Settings select User Management and click Attach.

Click on the Build Steps if it didn’t open automatically and click Add build step. Select Powershell from the Runner type drop-down. Give a name to the step and select Powershell mode and error output. Working directory will be MobileService/Scripts and Script file will be MobileService/Scripts/run-deploy.ps1. The last part is adding the Script arguments.

packageLocation parameter indicates where the package is located – it is defined by this value:

"%teamcity.build.checkoutDir%\Package"

This represent the Package folder in the checkout directory. The content of the Package folder will be generated by the Artfact dependency as you’ll see later.

The rest of the parameters value we extract from the Mobile Service publish profile as described in this post.

We need to link this build configuration to Mobile Service Team City build configuration we created in previous steps. Open the Dependencies and click on the Add new artifact dependency button. In the Depend on select the Mobile Service, select Last successful build from Get artifacts from and in Artifacts rules enter:

Package=>./Package

We’re almost done, one last step – we need to know which package was deployed to Test environment. Open the General Settings and in the Build number format enter:

Mobile Service-%dep.UserManagement_MobileService.build.number%

This will tell us which Mobiles service package version was deployed to Test environment.

Now we’re ready to run our deployment. On the Project page click on the ellipses Run button of the Deploy project and then click on the Dependencies tab. Select which build you want to deploy and click Run Build

The build run and the package was deployed successfully. As you can see the Test Deploy build indicates which Build package it used to deploy: #Mobile Service-0.0.2.37

Conclusion

With this blog post I’ve finished all the posts about building and deploying an Azure Mobile Service. I’ve started from installing and configuring TeamCity, creating PowerShell scripts to build and deploy up to configuring TeamCity to deploy on Test environment. Although it is concentrated on the Azure Mobile Service you might find some bits of it useful in other type of projects.

I hope you’ll find it useful.

Azure Mobile Service deployment with Team City part 6. Integrate SpecFlow with TeamCity

Fri, 28 Aug 2015 05:02:32 GMT

In the previous blog post I explained how to configure TeamCity to run a PowerShell script which will deploy an Azure Mobile Service.

After the Mobile Service was deployed we want to run acceptance tests. I’ve created a sample C# project using SpecFlow. It doesn’t have to be Acceptance Tests, I just wanted to give an example of how you’ll integrate SpecFlow with TeamCity. The solution contains the “Specifications” project which are a set of SpecFlow scenarios. SpecFlow has the ability to generate reports – we’ll be generating one report and integrate it with TeamCity.

We’ll create a new file – acceptance-tests.ps1 in the Scripts folder.

In order to generate a report we need to run a command which executes the NUnit tests as described in the documentation https://github.com/techtalk/SpecFlow/wiki/Reporting. For this purpose we need NUnit console app. I’ve added nuget package manually. Otherwise, it will install the package as a solution package.

<package id="NUnit.Runners" version="2.6.4" />

First step is to execute the acceptance tests with the nunit-console runner.

& $nunitRunner /nologo /labels /out=TestResult.txt /xml=TestResult.xml /framework:net-4.0 $acceptanceTests

It will generate two files: TestResult.txt and TestResult.xml. These files will be used when invoking SpecFlow report generation. TestResult name is the default name so if you don’t change it then in the next step you don’t have to provide additional parameters. You just need to provide the SpecFlow project file.

& $specFlow nunitexecutionreport "..\Source\Specifications\Specifications.csproj" /out:"..\TestResult.html"

This will generate TestResult.html report file in the root folder.

Another moment here I need to highlight – the specflow.exe is compiled for .NET 3.5 so it cannot load .NET 4.0 assemblies. You can find more details at Step Definition Report

For this reason we copy specflow.exe.config file to the packages folder.

Copy-Item -path "specflow.exe.config" -destination $specFlowFolder

Configure SpecFlow reporting in TeamCity

We can update our build so that after deployment it runs the SpecFlow Acceptance Tests and gives us the detailed report about the execution.

In the TeamCity configuration page open the Build Steps page. Add a new build step. As you might guess this will be another PowerShell configuration. The configuration is similar to the one we did before.

Working directory is MobileService/Scripts and Script file is MobileService/Scripts/acceptance-tests.ps1 with no parameters.

Next we need to configure TeamCity to display our SpecFlow report. First we add Build Feature – XML Report processing. The purpose of this is that TeamCity will take our TestsResult.xml file will parse it and report the results as the build results. In this way we can add out Acceptance Tests to be part of the CI process and they will be displayed in Test Results tab as well.

In the Build Configuration Settings page click on the Build Features and Add build feature. Select XML report processing from the drop down and select NUnit from the Report type. Add Scripts\TestResult.xml in the Monitoring rules.

Next step we’ll configure TeamCity result page to display the SpecFlow result page TestResult.html in a new tab.

Open the Administration page and click on the User Management project.

Click on the Report Tabs link.

Click on the Create new build report tab. In the new dialog enter the Tab title – that will be the title of the tab which appears in the build result page and Start page which in our case will be TestResult.html.

The Start page represents an artifact page which means that the TestResult.html page should be an artifact entity created by TeamCity. In order to do this go to the Build Configuration Settings and open the General Settings page. We have added already our package which gets deployed as an artifact. Now we need to add in the Artifact paths:

MobileService\TestResult.html=>.

Now when we run the build we have a nice SpecFlow report.

This finishes the full continuous integration and deployment of an Azure Mobile Service in TeamCitiy.

But there one last step which is outside of this deployment pipeline – in the next post we’ll configure TeamCity to deploy a package to Test environment which was deployed and tested on Dev environment.

< Previous

Azure Mobile Service deployment with Team City part 5. Configuring Mobile in TeamCity

Thu, 06 Aug 2015 09:08:03 GMT

In the previous post we finished to create all the PowerShell scripts. The build and deployment run locally. Now it’s time to create a TeamCity configuration for it.

Open the TeamCity web page and click on the arrow on the right hand side of User Management Project page and then Edit Settings from the menu.

Click on the Create build configuration.

Give it a name – I use Mobile Service and click Create.

It opens the Version Control Settings page where I will attach the VCS root previously created.

Next step is to create the build configuration. Click on the Build Steps and Add build step.

Select PowerShell Runner Type, specify the step name and select the PowerShell mode.

Click the Show advanced options link at the bottom of the page if you don’t see all the settings.

Select error value in Error Output drop down.

Enter MobileService/Scripts in Working directory

Enter the script file MobileService/Scripts/run-build.ps1

Make sure Execute .ps1 from external file is selected in Script execution mode.

Click Expand on the Script arguments and enter:

-version %build.number%

-contentPath "contentPath"

-computerName "computerName"

-userName "userName"

-password "password"

Replace all the necessary values as described in Azure Mobile Service deployment with Team City part 4. Deploying Azure Mobile Services.

Click Save.

We need to configure a few more settings.

Click on the General Settings and enter the Build number format. I use Major.Minor.Build.Revision pattern: 0.0.2.%build.counter%.

In the Artifact paths enter

MobileService\Artifacts=>Package

In our script at the build step we copy the package which we need to deploy in the Artifacts folder. Now we tell TeamCity to use that folder to create a build Artifact. You’ll see later how we use it do deploy to other environments.

Open the Failure Conditions from the left hand site and select “an error message is logged by build runner”. In some cases when the PowerShell returns an error, like failed to deploy the mobile service TeamCity will mark the build as green – success. When you select this option it will fail the build.

Now when you run this build it will execute all the PowerShell steps and will deploy the Azure Mobile Service.

In the next post we’ll configure SpecFlow to integrate with TeamCity.

< Previous

Azure Mobile Service deployment with Team City part 4. Deploying Azure Mobile Services

Wed, 22 Jul 2015 05:02:23 GMT

In the previous post I explained how to run a set of steps including restoring NuGet packages, building and running Unit Tests using psake with PowerShell.

The last step in our pipeline is the deployment script. This post will be shorter than others because it describes only the deployment of Azure Mobile Services. Basically this deployment issue triggered me to write an entire set of blog posts. At the moment Microsoft doesn’t provide a way of deploying Azure Mobile Service from the command line. The only option you have is using Visual Studio. But you can’t achieve much automation using Visual Studio.

I will create the deployment step in a separate script so we can use the same script when deploying on other environments. The script name is deploy-package.ps1 and it contains a few parameters.

packageLocation – this is the location where our package is stored. The location was defined during the build step. It was defined in $artifactDirectory variable which in our case was set to “[Root]\Artifacts”. We’ll configure this in TeamCity as well so we can reuse artifacts for deployments in other environments.

The rest of parameters are not really straightforward, we need to extract them from the Mobile Service Publish Profile. In Azure Management Portal open your Mobile Service you want to deploy to and click on the Dashboard. There should be “Download publish profile” link. Click on it and download the profile. The profile file is an XML file. Open it in a text editor like Sublime or Notepad++ and format the XML to be easier to read. The profile contains two publishing methods: MSDeploy and FTP. We’ll look at the MSDeploy. Search for the MSDeploy in publishMethod attribute and that will be the publishProfile XML element we’ll be looking at.

contentPath – search for msdeploySite and that will be the value you need. It should have the form of mobile$[MOBILE-SERVICE-NAME]

computerName – This was a bit difficult to figure out because you don’t have the value in the publish profile file. We’ll construct the value from different parts. Search for publishUrl in the profile file. My value is similar to this waws-prod-dbx-xxx.publish.azurewebsites.windows.net:443. To construct the computerName we’ll get the publishUrl value till the port number, for example waws-prod-dbx-xxx.publish.azurewebsites.windows.net and append this at the end /msdeploy.axd?site=[deploySite] . Replace the deploySite with the deploySite attribute value from the profile file. Also add https:// in front. At the end you should have a value similar to this:

https://waws-prod-dbx-xxx.publish.azurewebsites.windows.net/msdeploy.axd?site=mobile$my-mobile-service

userName – get the userName from the publish profile

password – get the password value from the publish profile

In order to deploy the mobile service we are going to use msdeploy application. You should have it installed on your machine but it’s missing from the Azure VM. Remote into the VM, download it from the http://www.microsoft.com/en-us/download/details.aspx?id=39277 and install it.

MsDeploy will be executed with these parameters

msdeploy.exe -verb:sync -source:contentPath=[PACKAGE_LOCATION] -dest:ContentPath=[CONTENT_PATH],ComputerName=[COMPUTER_NAME],UserName=[USER_NAME],Password=[PASSWORG],AuthType='Basic'

This is the source code which will deploy the package

function DeployPackage
{
    Param(
        [String]$packageLocation,
        [String]$contentPath,
        [String]$computerName,
        [String]$userName,
        [String]$password
    )

    $webDeployExePath = "C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\"

    $msdeploy = "$webDeployExePath\msdeploy.exe"
    if (!(Test-Path $msdeploy)) {
        throw "msdeploy.exe could not be found on this machine. MsDeploy location: $msdeploy"
    }

    "***** Start deploying the package from loction: $packageLocation *****"

    $arg1 = "-verb:sync" 
    $arg2 = "-source:contentPath=$packageLocation"
    $arg3 = "-dest:ContentPath='$contentPath',ComputerName='$computerName',UserName='$userName',Password='$password',AuthType='Basic'"

    & $msdeploy $arg1 $arg2 $arg3 $arg4
}

Now you should be able to build and deploy the Mobile Service to Azure instance from your machine. In the next post we’ll configure TeamCity to do this for us.

< Previous

Azure Mobile Service deployment with Team City part 3. Build Azure Mobile Service with PowerShell using psake

Thu, 16 Jul 2015 05:02:40 GMT

TeamCity is a very powerful tool and you can take advantage of all its configuration options to create your CI and CD. Although TeamCity provides you with almost everything you need, like restoring packages, update version, build, running unit tests, etc. I’m going to write all these steps in a PowerShell script. It is easier to use what TeamCity offers from the start but when the complexity of building and deploying increases it will be difficult to maintain.

Having the deployment process as a set of scripts will give you some advantages, like:

Run and test the deployment process on your machine
Evolve the deployment system incrementally
Ability to test every step in isolation
Checking changes in source control and ability to revert to previous versions if needed

The scripts will be written in PowerShell and I will use psake which is a PowerShell tool to provide task-oriented dependencies.

Initially we’ll start with three scripts:

local.ps1 – we’ll use this script to run the entire set of script on local machine; it contains default parameters and it executes run-build.ps1
run-build.ps1 – the script is called by TeamCity providing all the necessary parameters. It invokes the build.ps1 script using psake module
builid.ps1 – contains all the steps necessary to build the project

Tools

First we need to get psake scripts from the git releases page and copy them to the Tools folder. We need the nuget.exe as well. Download it from Command-Line Utility URL . Copy nuget.exe in the Tools folder.

Local script

All the scripts are located in the Scripts folder.

local.ps1 script clears the screen and executes the run-build.ps1 script. It contains a few default parameters. One of the parameter is debugConfiguration. We use that for debugging purposes. For example when we work on the deployment task we might not want to run all the tasks which are time consuming, like restore packages so we’ll ignore it.

Run-build script

The run-build.ps1 script imports psake module and executes build.ps1 script in the context of the psake module. It invokes the script with parameters which don’t have default values and properties which have default values.

Build script

All the steps before running the build and the build itself are done in this build.ps1 script.

We’ll start with changing how psake prints out the tasks it runs. This will make a better separation between tasks and will be easier to read.

FormatTaskName "$([Environment]::NewLine)==================== $(Get-Date -format T) - Executing {0} ===================="

We’ll use the precondition parameter to conditionally run a task. For example, if we don’t want to restore packages we’ll use the $debugConfiguration.restorePackage parameter.

Task RestoreNuGetPackages -Depends Clean -Precondition {return $debugConfiguration -eq $null -or $debugConfiguration.restorePackage } {

The task will run when precondition returns true. I check for null value of the debugConfiguration variable because it will be null when running from TeamCity so we don’t want to skip the step.

Bear in mind that if the task execution depends on another task then that task will not run if precondition of the task in execution returns false.

We’ll start with adding the default task.

Task Default -Depends DeployPackage

Clean

First of all we need to clean everything. For that we’ll build the solution with Clean target and also delete the packages folder.

Task Clean -Precondition { return $debugConfiguration -eq $null -or $debugConfiguration.clean } {
 Exec {
        msbuild $solutionToBuild /t:Clean /verbosity:$verbosity /nologo /p:Configuration=$config /p:VisualStudioVersion=12.0
    }

  if (Test-Path "..\Source\packages") {
     Remove-Item "..\Source\packages" -Recurse -Force -ErrorAction Stop
  }
  else {
    "Didn't find the 'packages' folder."
  }
}

Restore packages

Every single build needs to restore all the packages, in this way we make sure that packages are not missing on the build machine.

Task RestoreNuGetPackages -Depends Clean -Precondition { return $debugConfiguration -eq $null -or $debugConfiguration.restorePackage } {
    if (!(Test-Path $nugetExe)){
        throw "nuget.exe could not be found on this machine. Please check: $nugetExe"
    }
    Exec {
      & $nugetExe restore $solutionToBuild
    }
}

Our mobile service project references a NuGet package hosted on the TeamCity machine. But the NuGet feed requires authentication. In order to restore that package on the TeamCity machine during the build process we need to allow the restore process to authenticate to that NuGet feed. There is a command line we need to run on the TeamCity VM.

Login on the TeamCity server and make sure that you use the same account you used when you installed the TeamCity agent. It’s important that the agent runs under the same account. We configured the agent in step 1 where I mentioned that. NuGet should add the configuration file (NuGet.config) in the same user’s folder.

For example, if you run the agent under the ‘teamcity’ user name then when you add the NuGet source as below (run the below command) it will create or update the file in this location:

C:\Users\teamcity\AppData\Roaming\NuGet\NuGet.Config

This is the command line you need to run:

NuGet.exe Sources Add –Name [GIVE_A_NAME] -Source [TEAMCITY_FEED] –UserName [USER_NAME] –Password [PASSWORD]

Sources – TeamCity NuGet feed. Check the configure NuGet server post

UserName – user name you provided when you setup TeamCity. You can create a new user name just for this purpose but in this case you’ll need to run the agent under this user

Password – user name’s password

Update assembly version

There are different methods to update the assembly version. You can keep the version in one AssemblyInfo.cs file and add that file as a link to all the projects but I don’t like this idea because you can forget to do that and some of your libraries will not have the version updated. Instead of that I iterate through all the projects and update the version for every single AssemblyInfo.cs file.

Task UpdateVersion -Precondition { return $debugConfiguration -eq $null -or $debugConfiguration.updateVersion } {
    (Get-ChildItem -Path $sourceDirectory -Filter AssemblyInfo.cs -Recurse) |
    ForEach-Object {
      (Get-Content $_.FullName) |
        ForEach-Object {
          $_ -replace 'AssemblyVersion.+$',"AssemblyVersion(`"$version`")]" `
          -replace 'AssemblyFileVersion.+$',"AssemblyFileVersion(`"$version`")]"
        } |
        Out-File $_.FullName
    }
}

Build

The build process should create a package which will be deployed to Azure. In order to do this we’ll use DeployOnBuild=true and PublishProfile=PublishProfile.xml parameters.

The PublishProfile.pubxml file doesn’t exist. We need to generate it. In order to do this we have the pubxml.template file in the Scripts folder. It contains the following xml:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <WebPublishMethod>FileSystem</WebPublishMethod>
    <LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
    <LastUsedPlatform>Any CPU</LastUsedPlatform>
    <SiteUrlToLaunchAfterPublish />
    <LaunchSiteAfterPublish>False</LaunchSiteAfterPublish>
    <ExcludeApp_Data>True</ExcludeApp_Data>
    <publishUrl>{0}</publishUrl>
    <DeleteExistingFiles>True</DeleteExistingFiles>
  </PropertyGroup>
</Project>

You can change it if you need to. We’re interested in the publishUrl value – we need to populate it during the build process with the package location. If you’re going to have a fixed package location then you can hard-code it but in our case the location will be driven by the TeamCity. We’ll generate the package in the “[Root]\Artifacts” folder. Root is the folder where our Scripts and Source folders are located.

The PublishProfile.pubxml file is generated in the method “GetPublishProfile” and will be saved in “[Root]\Artifacts” folder. Later it is overwritten by the build with the package. To some extend this simulates the same process you have when you deploy from Visual Studio.

function GetPublishProfile() {
    # Get the publish xml template and generate the .pubxml file
    $scriptPath = Split-Path -parent $PSCommandPath

    if (Test-Path $artifactDirectory) {
        Remove-Item $artifactDirectory -Recurse -Force -ErrorAction Stop
    }

    [String]$template = Get-Content $scriptPath\pubxml.template

    mkdir $artifactDirectory | Out-Null
    $xml = $template -f $artifactDirectory
    $outputPublishProfile = Join-Path $artifactDirectory "PublishProfile.pubxml"
    $xml | Out-File -Encoding utf8 -FilePath $outputPublishProfile

    return $outputPublishProfile
}

Task Build -Depends RestoreNuGetPackages, UpdateVersion {
    $publishProfile = GetPublishProfile 

    Exec {
        msbuild $projectToBuild /p:DeployOnBuild=true /p:PublishProfile=$publishProfile /verbosity:$verbosity /nologo /p:Configuration=$config /p:VisualStudioVersion=12.0
    }
}

Unit Tests

All the Unit Tests were implemented using xunit. First we need to build the solution which will create the Test*.dll files. After that we’ll run every Test*.dll file by xunit.exe.

xunit.exe file is added as a NuGet package. In order to do that we need to add this to our Test project, otherwise it will create a .nuget folder with packages.config file and we’ll put it under the solution folder. You can add it as I NuGet package for the solution but I don't really like it for small projects.

  <package id="xunit.runner.console" version="2.0.0" />

The full source code of the Unit Test

Task Test -Depends Build {
  if (!(Test-Path $xunitConsole))
  {
    throw "xunit.console.exe does not exist. Please check $xunitConsole file."
  }

   "************* Build solution [$solutionToBuild] for Unit Testing *************"
  # Need to run the solution to build all the tests. The Build Task run only the csproj file
  exec {
    msbuild $solutionToBuild /verbosity:m /p:Configuration=$config /p:VisualStudioVersion=12.0 /nologo
  }

  $assembliesToTest = (Get-ChildItem "$sourceDirectory" -Recurse -Include "*Test*.dll" -Name | Select-String "bin")

  $atLeastOneTestRun = $false

  "************* Running Unit Tests *************"
  foreach ($testFile in $assembliesToTest){
    "*************** Testing $testFile ***************"
    $fullNameTestFile = Join-Path $sourceDirectory $testFile
    
    & $xunitConsole $fullNameTestFile
    $atLeastOneTestRun = $true
  }

  if ($atLeastOneTestRun -eq $false){
    Write-Output "Unit Tests didn't run!"
    exit(1)
  }
}

Now we can build and test our project. In the next post I will explain how to deploy an Azure Mobile Service.

< Previous post

Azure Mobile Service deployment with Team City part 2. Configure TeamCity NuGet Server

Mon, 13 Jul 2015 05:00:01 GMT

In the previous post I explained how to install TeamCity on Azure and configure it.

In this post I will create a TeamCity configuration which will publish to a NuGet Server hosted in TeamCity.

You can find the source code used by these series of post at https://github.com/ralbu/TeamCityAzure

Common project

As this is a fresh installation of TeamCity there are no projects. Let’s create one. I will name it User Management. It will contain two configurations:

Common – a NuGet package used by the main project (User Management)
User Management – an Azure Mobile Service project

Click the Create project button

Enter the Name of the project and optionally the description and click Create.

After the project was created click on the Create build configuration button

The first project configuration is our Common library hosted on a NuGet server. We’ll use the TeamCity NuGet plugin to host our NuGet Common package.

Enter the required data and click Create.

In the next step we configure the source control. For this set of tutorials I host the project to GitHub in a public repository. As this is a public repository I use Anonymous as authentication method. There are other options you can choose from, like Password or Private Key. Click Test Connection and if everything is ok click Create.

Both projects – NuGet package and Azure Mobile Service used in this set of blog posts are under the same GitHub repository so I will reuse this VCS root in both projects.

Prerequisites for running builds

Next we’ll create build configurations but before that we need to install the necessary software and configure NuGet server on TeamCity.

We are not going to install Visual Studio on the build machine, although that will be easier. We’ll install only the minimum which is needed to build our projects. Remote into the VM and from https://www.visualstudio.com/en-us/downloads download “Microsoft Build Tools” and install it.
You might also need to install “.NET Framework 4.5.1 Developer Pack”. If you want to have a clean machine I would skip this step and install it later if the build fails. I had to install it because of the xUnit framework. If you are not sure you need “.NET Framework 4.5.1 Developer Pack” then first start with “.NET Framework 4.5” installation.
In order to deploy our mobile services we’ll be using Web Deploy. Install it from this location: http://www.microsoft.com/en-us/download/details.aspx?id=39277

You’ll need to restart the TeamCity agent. Open the Services application and search for Team City Build Agent and restart it.

We need to manually copy the next two folders

Copy the folder C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications to the same location of TeamCity server. The reason for doing that is because we don’t have Visual Studio installed on the TeamCity machine. The build process uses targets from Microsoft.WebApplication.targets file to build the Web Application.
Copy the folder C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web to TeamCity machine. Make sure you copy this folder. These targets are used in generating packages. If you don’t have this targets it will build the solution but it will not create a package which is used in deployment. It is not easy to figure out if you missed it because the solution will build successfully but the package will not be created and it won’t give you any error or warning.

Configure NuGet Server

In the TeamCity web page, click on the Administration and then in the left hand side under Integration click NuGet. On the NuGet Server tab click Enable button. We are going to use authenticated feed and not the public one. Copy the link to the authenticated feed URL, we’ll use it later. Click on the NuGet.exe tab and then on Fetch NuGet button. Select the NuGet version and select Set as Default. At the time of this writing the latest NuGet is 2.8.5.

Creating build configurations

In this step we’ll create our first build configuration. As the first step we’ll build our solution.

Click on the Build Steps in the Build Configuration Settings and click Add build step

From the New Build Step page select Visual Studio (sln) Runner type and provide the rest of the settings as below and click Save.

Click the Run button if you want to make sure that everything is ok at this step.

In the next step we’ll add the build configuration to create a NuGet package and publish it on TeamCity’s NuGet server.

First of all make sure you have the NuGet spec file. If you don’t then the fastest way of generating it is to open the command line where your .csproj file is located and run:

nuget spec

Open it and adjust it accordingly.

I’m not going to go in details about this step, just have a look at the settings below, and if you want to find out more about it then go to my other blog – Hosting NuGet in TeamCity and consume it in Visual Studio where I explained all the settings.

Click Save and this is how you would configure a NuGet Server. In the next blog post I will describe how to create the main project configuration as a PowerShell script and configure it in TeamCity

Azure Mobile Service deployment with Team City part 1. Team City Installation

Wed, 08 Jul 2015 04:00:00 GMT

In these series of blog posts I will explain how to host a TeamCity server on an Azure Virtual Machine, configure it and create TeamCity configuration to build and deploy an Azure Mobile Service.

Azure Mobile Service deployment with Team City part 1. Team City Installation (this article)

Azure Mobile Service deployment with Team City part 2. Configure TeamCity NuGet Server

Azure Mobile Service deployment with Team City part 3. Build Azure Mobile Service with PowerShell using psake

Azure Mobile Service deployment with Team City part 4. Deploying Azure Mobile Services

Azure Mobile Service deployment with Team City part 5. Configuring Mobile in TeamCity

Azure Mobile Service deployment with Team City part 6. Integrate SpecFlow with TeamCity

Azure Mobile Service deployment with Team City part 7. Deployment to Test environment

Recently Azure introduced a new concept for Mobile Services – Mobile App. You can access it in the Azure Preview Portal. This blog explains Azure Mobile Services which can be accessed at Azure Management Portal. The reason for doing this is that the Mobile App is still in preview and for the current Mobile Service Microsoft doesn’t provide an easy way of doing continuous deployment. The only way you can deploy it is by using Visual Studio. There are no API either for Azure PowerShell or for Command Line Interface.

I will use Azure Preview Portal every time apart from the time when there are operations which I can’t do using it. In this case I will use Azure Management Portal.

All the examples and UI screenshots are based on TeamCity version 9.0.4.

These series will walk you through all the steps from zero to a fully working Continuous Integration and Deployment on Dev and Test environment.

Creating an Azure Virtual Machine

Open the Azure Preview Portal and click the “+” button, select Compute and from the list select Windows Server 2012 R2 Datacenter.

Provide all the details on the opened blade.

Host Name – name of your VM.
User Name – user name you’ll use to log in to the Remote Machine
Password – password to be used to log into the Remote Machine
Pricing Tier – select the size of your machine. Check the prices on this page: http://azure.microsoft.com/en-gb/pricing/details/virtual-machines. The cheapest machine is Basic Tier A0. Even if you do this as a PoC this machine is not powerful enough. You’ll spend too much time waiting for the installation of TeamCity and the machine will be too slow. Basic A1 is OK but I would recommend Basic A2. You can start with that and later you can upgrade the machine.
Resource Group – this is a container to help you manage a set of resources, like provisioning them. In this I will create a new Resource Group
Subscription – select your subscription
Location – choose a location, preferably the same location where all your services are

Click Create and after less than 10 minutes you’ll have the machine up and running.

TeamCity Installation

After the machine was provisioned, on the Azure Management Portal open the new created VM instance and click on the Connect button. As it stands now, if you download the Remote Desktop Connection file from the Azure Preview Portal you’ll have to enter the machine name manually.

It will download a Remote Desktop Connection file. Double click the file and then enter the user name and password you provided when you created the VM. After you’ve logged in, open the Internet Explorer and download TeamCity.

Now let’s install TeamCity on that VM. I will skip the obvious steps where you need to accept license, etc.

TeamCity installation directory – this is where the TeamCity server is installed. It will contain the TeamCity configuration, binaries. I will keep the default value c:\TeamCity

On the next step we’ll install all the components.

Next is the TeamCity Data Directory. It is important to select the right Data Directory location. TeamCity stores configuration settings, artifacts, build logs, etc. By default it stores all the configuration settings. It is recommended that you configure TeamCity to store all the configuration settings in the Database. Do make sure you backup this folder regularly. Due to the fact that Data Directory stores all the build logs and artifacts and can grow very large it is recommended to select a non-system disk. For the sake of this demo I will leave the default value: C:\ProgramData\JetBrains\TeamCity

Will keep the default port 80

The TeamCity server installation is now finished.

Next we’ll configure the Build Agent.

I will use System Account to run TeamCity but you might want to select a user account with less privileges.

For the Agent we’ll select a user account. I will explain the reason for that later. Select the account you used to log into VM or if you want you can create a new one.

And will start all the services.

After clicking the Next button it will finish the configuration, start the services and open the default page: http://localhost. Click on the Proceed button and next select the data base type. I will select Internal (HSQLDB) for the sake of this tutorial but in your case it depends on the type of server. If you just want to try things out and are not worried about losing configurations use HSQLDB, otherwise you’ll need a separate database. Depending on which type you select you’ll have more configuration to enter. Click Proceed and wait till TeamCity is starting up. Accept the license agreement and click Continue.

TeamCity will ask you to create an administrator account. Enter the user name and password and click Create Account.

Configure TeamCity to be accessible from web

Now that TeamCity is up and running there a few steps to be done to be able to access TeamCity from the web. First we need to setup an endpoint to direct inbound traffic to the TeamCity VM. Open the VM in Azure Preview Portal, select All settings and click on the Endpoints. Provide a name, select TCP from the Protocol list, and enter public and private ports. I used 80 for both. The public port is used by Azure load balancer. The private port is used by the VM to listen for the incoming traffic. It should have the same value we set when installed TeamCity.

We need to configure TeamCity VM firewall to allow incoming traffic for the TCP protocol and private port corresponding to the endpoint configuration. Remote into the VM and open Server Manager > Tools > Windows Firewall with Advanced Security. Select the Inbound Rules, right click and click “New Rule…” Select Port, TCP rule and port number. It should be the same port you used when you installed TeamCity and private port for endpoint configuration. Allow for All connections and give it a name.

Now fire up your browser and you should be able to open TeamCity login page. If you are not sure what’s the name of the TeamCity VM go to the Azure Preview Portal and check the DNS name in the Essentials area.

This finishes TeamCity installation and configuration. In the next part we’ll create TeamCity build configuration and configure a NuGet Server.

TeamCity Build Parameters for PowerShell

Tue, 28 Jan 2014 22:48:00 GMT

In this article I will describe how you can add custom parameters to your TeamCity build configuration and read them in Powershell. Although adding parameters is not difficult and it is documented ok it is not really straightforward and you'd need a few trials until get it right.

Let's say we have a web project which needs to be deployed. For this purpose we'll add two parameters:

A boolean with the name deploy
A path where the service will be deployed.

This is just an example of how to set two parameters and read them in powershell. You can use this for your own scenarios, not just for setting up deployment

Open your TeamCity configuration project and on the Configuration Steps click the Build Parameters. Click 'Add new parameter' button and provide the name 'Deploy'. Select Configuration parameter from the Kind drop down. Type false in the Value field. Click on the Edit… button, give it a label and description. In Type select Checkbox and set Checked value to true and Unchecked to false. Click Save.

Add new parameter for the deployment path. I named it DeployPath with Text Type and Allowed Value to Any

Next we need to add a PowerShell script. In the TeamCity Build Steps add a new build and set the type drop down to Powershell.

Create a PowerShell file on your disk and set the path to that file (in the Script file text box).

In the Script arguments add the following:

-deploy:%Deploy% 

-deployPath:%DeployPath%

Open the PowerShell file you’ve created on the hard disck and add the following lines.

param 

( 

[Parameter(Mandatory=$false)] [String]$deploy, 

[Parameter(Mandatory=$false)] [String]$deployPath 

) 

Write-Host "Deploy " + $deploy 

Write-Host "Deploy path is: " + $deployPath

Now you need to add the part which will deploy your web site or do whatever you need.

You can read the TeamCity parameters inside PowerShell but I prefer to set them outside of PowerShell and feed to PowerShell as command parameters. In this way your script doesn't depend on TeamCity and you can test it locally.

Hosting NuGet in TeamCity and consume it in Visual Studio

Sat, 21 Sep 2013 14:35:00 GMT

Introduction

This post describes the setup of NuGet package inside TeamCity and configuration of your Visual Studio to consume the hosted packages. TeamCity version 7.1 is used.

When you work on a big or medium projects you’ll end up having at least one common library. If you keep everything in one solution then you don’t have problems with sharing the common library – you reference the common project to all other projects which need it.

How about the case when you have multiple separate solutions/projects and want to use the common library. In this cases you have two options: a) add the common library into all the projects as Add Existing Project and b) add a reference to the common dll file. With both approaches you have tackle a set of issues, like how to update the common library and not to break the projects using it; what if you need to use it for a project in a location different to the library, let’s say common library is located on c:/project but the project using it is located on D:/WebSites. These are just a few issues but enough to give you a headache.

All these issues will go away by implementing your common libraries as NuGet packages. You can host these packages on the NuGet web site but you might not want to do it. Here I explain how to host them in TeamCity.

Pre NuGet Build Configuration setup

Will start with standard build configuration steps. In TeamCity create a new Build Configuration. Set the Build number format as it will help to keep track on the versioning and make the update process easier. Set Version Control settings.

Add a Build Step which will build your package solution. If needed add /p:Configuration=Release to Command line parameters to build the release.

Add a unit test build step if it is the case. For example select the MSTest as Runner type if you do MS Unit testing. Add the following **\bin\**\*.Tests.dll in the List assembly files.

NuGet package configuration

Next is the part which is most interested for us. But before that make sure you have the NuGet set in Administration > NuGet Settings.

Add a new Build Step and in the Runner type select NuGetPack. If you set the NuGet settings you should have NuGet.exe dropdown with the NuGet version.

In the Specification files select the project you want to create a package from.

Update Version to %build.number% if you want to keep the same version you set in General Settings of your build configuration.

Set the Output Directory. For instance, Build\packages

Make sure you check the Publish created packages to build artifacts.

Also you might want to check Include sources and symbols but not mandatory.

NOTE:

In the Build Steps screen add AssemblyInfo patched in Additional Build Features so it will update the dll version in order to keep your files versioned.

That's all you need to set for TeamCity to create NuGet packages.

Visual Studio configuration

Next we need to configure VS to get the package from TeamCity.

In VS open Tools > Library Package Manager > Package Manager Settings. Select the Packages Sources and click the "+" to add a new sources. Give it a name and set the Source. If you haven't figured it out go into TeamCity > Administrator > NuGetSettings > NuGet Server and get the URL, either Autenticated Feed URL or Public Feed URL, depending how you configured it.

In order to add the common library to your project follow the same steps you do when you add a standard NuGet package to your project except you'll see now an additional repository - the one you’ve just created. That’s it – you now have your own NuGet package repository and you can add it to all your projects.

Using NuGet without committing packages to source control

When you add the NuGet package to your solution it will be added to your source control. So all the dll files will be committed to the source control. Starting with NuGet version 2 you have the option to download the library when you compile so the missing libraries will be downloaded on demand instead of keeping them on the source control. In order to enable this in VS open Tools > Library Package Manager > Package Manager Settings and select General. Check the Allow NuGet to download missing packages during build. This should be done on every machine. Next right click on the solution which uses the NuGet packages and select Enable NuGet Package Restore.

When you enable NuGet Package Restore a new .nuget folder will be created. It contains NuGet.exe file. It is executed during the build process to install the missing packages. This file should be added to source control. So if you have all your *.exe files ignored make sure NuGet.exe is not excluded, otherwise the build will fail.

Conclusion

One of the best way of sharing your libraries is using NuGet packages. You need to setup a TeamCity configuration build and configure the Visual Studio to access it. This post describes the steps you need to follow.

Git versioning for .NET projects with TeamCity

Thu, 28 Mar 2013 05:26:00 GMT

TeamCity has a nice feature which allows to create a build number automatically with every build. For example, MyLib.dll has version 1.2.3.0. When configuring TeamCity in the “Build number format” the value specified like {0} will increase with every build. So if you set “Build number format” 1.2.3.{0} then the last number (revision number) will increase with every build.

For a .NET project if you provide the AssemblyInfo patcher feature for your build configuration then the AssemblyVersion and AssemblyFileVersion will be updated automatically with the build number.

This works well for the cases when only one number should be changed. But you might want to have two numbers updated with your build, build and revision values. With Subversion you can include the repository Revision number as part of the building number. Git doesn’t provide this number because each commit is represented by a SHA1 hash.

The solution will be to take advantage of the number of commits since the most recent tag. This is made available through the git describe command.

This will work only if you have at least one tag in your repository and every time you need to change you version you need to create a new tag. Also you need to push your tag to the remote repository as it is not pushed automatically.

Let’s add a new tag to your commit

git tag v1.2

And use describe command

git describe --tags --long

Will display

v1.2-0-gb2d5397

The --tags flag allows to use lightweight tag and --long takes care to display the long format – the tag, the number of commits and the abbreviated commit name.

The 0 number represent the number of commits.

The describe command works fine but what happens if a new tag is created and its purpose is not for versioning. To fix this will add the --match flag so your command will become:

git describe --tags –long --match v?.?

This will display only the tags which are in format v?.?, v1.2 for instance. If you want to keep your versioning tags differently, for example version1.2 then you need to change v?.? to version?.?

That is all good but how can we use it with TeamCity? We will create a Powershell script which parses the output and creates the build number.

In TeamCity “Runner type” is set as Powershell and in the “Script arguments” %build.number% is provided.

Will use the following script

Param ([string]$build_num)

$git_version = (git describe --tags --long --match v?.? | Select-String -pattern '(?<major>[0-9]+)\.(?<minor>[0-9]+)-(?<seq>[0-9]+)-(?<hash>[a-z0-9]+)').Matches[0].Groups

$git_describe = $git_version[0].Value

$version = [string]::Join('.', @(
  $git_version['major'],
  $git_version['minor'],
  $git_version['seq'],
  $build_num 
))

Write-Host "##teamcity[buildNumber '$version']"

Line 1: reads the provided %build.number% from TeamCity
Line 3: uses the git describe command and creates an object with all version parts
Lines 7-12: create a version string based on the git tag and TeamCity
Line 14: uses TeamCity service messages to pass the information to TeamCity

This step should be added before the step where you compile your project.