Powershell

Become a Git command line guru

Tue, 26 Jul 2016 05:02:37 GMT

Git became one of the widely used Source Control System. If you work on a Windows machine you may rely on your IDE or other tools like GitHub Desktop or Atlassian's SourceTree to work with git. But in order to get all the power git offers you need to start using git from the command line. Don't get put off by the fact that git on windows is limited. With the right tools and configurations you'll enjoy it and finally you'll start liking it.
The default command line solution for git is to use Git Bash but we'll use ConEmu with PowerShell Posh Git module. You'll be very pleased how it works.

Installation

Git

If you have not installed git yet let’s do it now. Either download it from https://git-scm.com/download or run chocolately:

choco install git.install

You can add –notSilent in the command line in order to have the installation wizard if you want to provide different options.

ConEmu

Install ConEmu from https://github.com/Maximus5/ConEmu or run chocolately:

choco install conemu

Posh Git

After ConEmu was installed we need to install Posh Git

Run

choco install poshgit

Or go to the web site https://github.com/dahlbyk/posh-git and follow the instructions

Note:

When you install poshgit make sure that you have git installed already and the Environment path for git was set before opening the PowerShell. If for some reasons you don't want to have git path in the Environment variable then add the following to your c:\Users\[UserName]\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 file.

$env:path += ";" + (Get-Item "Env:ProgramFiles(x86)").Value + "\Git\bin"

Replace ProgramFiles(x86) with ProgramFiles if you have installed git in Program Files.

The installation of posh-git will add the following in the Microsoft.PowerShell_profile.ps1

# Load posh-git example profile
. 'C:\tools\poshgit\dahlbyk-posh-git-869d4c5\profile.example.ps1'

ConEmu Configuration

Open ConEmu and navigate to a git repository. In my case, I've opened xunit. As you can see from the image the command line has this information: I am on the master branch, 1 file added and two edited.

We can add task bar jump list in ConEmu. In this case when I right click on the ConEmu in the task bar it will open a PowerSell console with poshgit at that location.

Click on the icon on the left hand side of the ConEmu and select Settings… and then Startup > Tasks

By default every item has Taskbar jump lists checked. This means that all the items from the list will appear in Task bar list. We don't need to have all of them, so go though everyone and deselect what you don't need.

The list in the Predefined tasks contains all tabs you can open when creating a new Console. Let’s create one which will open PowerShell with poshgit in C:\Projects:

Click the + button and add the following:

Name – let’s name it Projects.
Task parameters - a path where you want the console to open, for example: /dir "c:\Projects"
Start console: powershell.exe

Click Up to move it to a desired location.

Click Save settings with Shift key pressed because we don’t want to close the dialog yet.

In the next step we'll add our new created Task to the Task bar jump list. Go to the Main > Task bar. At the bottom of the window check Add ConEmu tasks and click Update Now!

Click Save settings and we're done with the ConEmu settings. Now when you right click on Task bar you can open a new ConEmu instance directly into you Git local repository.

Git colours

Let's set a few colours in Git. If you use PowerShell colour scheme in ConEmu (I prefer ConEmu scheme) then the text in the default red colour will be difficult to read on the blue background. You fix this by adding the following in the Microsoft.PowerShell_profile.ps1 file.

$global:GitPromptSettings.WorkingForegroundColor    = [ConsoleColor]::DarkGray

At this point all the PowerShell configuration is done. But I don't like the default git colours so I will update a few colours for git. This is nothing to do with PowerShell and this changes will apply to Git Bash as well.

git config --global color.status.added "green normal bold"
git config --global color.status.header "cyan normal bold"
git config --global color.status.updated "green normal bold"
git config --global color.status.changed "cyan"
git config --global color.branch.remote "blue normal bold"
git config --global color.branch.current "green normal bold"
git config --global color.branch.local "green dim"

git configuration

Store git credentials

An easy way to store git credentials so you don’t have to type them every time is to use Git Credential Manager for Windows, download it from https://github.com/Microsoft/Git-Credential-Manager-for-Windows

Compare configuration

Before committing my files I like to compare my local changes with the remote version. I do that using Beyond Compare.

I run the comparison from the command line:

git difftool

And configure git to use Beyond Compare:

git config --global merge.tool bc
git config --global mergetool.bc.path "c:/Program Files/Beyond Compare 4/bcomp.exe"
git config --global difftool.prompt false

And the last step, I don’t want to write difftool every time so let’s create an alias:

git config --global alias.dt difftool

Now it is just enough to type dt and it will run the comparer.

Conclusion

As you can see there’s enough work to do in order to have a proper git command line on Windows. But you don’t have to configure everything. The most important thing is ConEmu and poshgit.

Running Unit Tests as part of Continuous Integration of VSTS / VSO

Tue, 05 Jul 2016 09:00:00 GMT

In my previous blog I explained how to setup from scratch and deploy to Azure using VSTS. As I mentioned in the blog I left the configuration of Unit Testing for another time.

In this article I will explain how you set up and run your Unit Tests as part of CI/CD process using VSTS.

There are a few ways to setup Unit Tests depending on what you want to achieve. We can run the Unit Tests from a PowerShell script or we can use the Visual Studio Test build step which VSTS team created for us. Let’s start with PowerShell first.

We’ll use the same project as in the previous post – OfficeInventory. The Unit Test project is a standard .NET library using xUnit library. The process will be similar if you use a different Unit Test library, like NUnit.

Configuring PowerShell

When using xUnit you should make sure that the console runner is added as package so it will be restored during the build. We will use the console application to run the Unit Tests.

At the root folder of the project – the same level with .sln I added the Scripts folder. The folder will contain run-unittests.ps1 PowerShell script.

We provide two input parameters to the script, the xunit console application path and the path we want to search for the tests projects.

param (
    [Parameter(Mandatory=$true)][String] $xunitConsole,
    [Parameter(Mandatory=$true)][String] $sourceDirectory
)

Next we’ll search for all the Unit Tests files we want to test excluding Java Script projects.

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

Now that we have all the Unit Test files we want to run let’s execute them.

foreach ($testFile in $assembliesToTest) {

  $fileNameOnly = Split-Path $testFile -Leaf
  $unitTestFileName = Join-Path $sourceDirectory ($fileNameOnly + "-XunitTestResult.xml")

  $fullNameTestFile = Join-Path $sourceDirectory $testFile

  & $xunitConsole $fullNameTestFile -xml $unitTestFileName
}

In the $unitTestFileName we store the result of our Unit Test execution. We’ll use this in the Publish Test Result build step.

Here’s the full PowerShell script

param (
    [Parameter(Mandatory=$true)][String] $xunitConsole,
    [Parameter(Mandatory=$true)][String] $sourceDirectory
)

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

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

$atLeastOneTestRun = $false

Write-Host "[Debug] ************* Running Unit Tests *************"

foreach ($testFile in $assembliesToTest) {
    Write-Host "[Debug] *************** Testing $testFile ***************"

  $fileNameOnly = Split-Path $testFile -Leaf
  $unitTestFileName = Join-Path $sourceDirectory ($fileNameOnly + "-XunitTestResult.xml")

  $fullNameTestFile = Join-Path $sourceDirectory $testFile

  & $xunitConsole $fullNameTestFile -xml $unitTestFileName
  $atLeastOneTestRun = $true
}

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

The script is ready, lets add the build steps. Edit the configuration build and in the Add tasks select PowerShell Scripts.

And after that add Publish Test Results.

Close the dialog and make sure both tasks are added after the Build task and before the Publish Artifact task.

Select the PowerShell tasks and configure the following

- Type: File Path

- Script filename: scripts/run-unittests.ps1

- Arguments: -xunitConsole "$(Build.Repository.LocalPath)\packages\xunit.runner.console.2.1.0\tools\xunit.console.exe" -sourceDirectory "$(Build.Repository.LocalPath)"

Select the Publish Test Results and configure these parameters

- Test Result Format: XUnit

- Test Results Files: **/*-XunitTestResult.xml

Now it’s time to run the build. You can see the Tests Results in the Summary page.

Configuring the Visual Studio Test step

For this configuration we will use a Visual Studio Test task. First of all, make sure that the Unit Test project has xunit.runner.visualstudio package if you are using the xUnit framework.

Add a new build step as in the below image. That will be a Visual Studio Test step

You don’t have to do anything in this step, the default parameters will work ok, unless you need more features, like code coverage, running JavaScript, etc.

The default configuration will include all the projects containing the name tests and exclude the obj folder.

Conclusion

In this post I explained two ways you can run your Unit Tests during the build process using VSTS / VSO.

First way is to execute a PowerShell script which will find all the tests you want to run and using a Publish Tests Results to publish the tests. If you’re using xUnit you need to make sure you have xunit.runner.console included as a NuGet package.

The second option is easier but is not as flexible. In this case you need to have xunit.runner.visualstudio NuGet package.

Visual Studio Online - output colouring by tag

Wed, 23 Sep 2015 06:09:32 GMT

I started being more involved in continuous integration and deployment using Visual Studio Online which is ‘the new‘ TFS hosted in Azure.

I've discovered an interesting and useful feature when using it PowerShell. When you use Write-Host if you add [Debug], [Warning] and [Error] in your output string then you get a nice colour in the Console and Logs pages of the build result.

Have a look at the below images.

In this example the following output was used:

Write-Host "[Debug] Debug value"
Write-Host "[Warning] Warning value"
Write-Host "[Error] Error value"

As you can see the Console doesn't shows the value in square brackets.

This worked for me in both Azure hosted and local hosted agent. I guess it should be the same on the TFS hosted on premises.

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 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 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.

PowerShell with Visual Studio

Sat, 20 Jun 2015 05:02:26 GMT

I started doing more and more PowerShell recently to automate provisioning environments on Azure and for CI & CD. I use Sublime for my editing - it's the best editor I've used but what I miss is a good vim plugin - or perhaps I haven't found that one. I use vim editor with my Visual Studio 2013.

Visual Studio might sound like not the tool for writing PowerShell scripts but with the right plugin will make your life easier.

Here you install Visual Studio plugin: https://visualstudiogallery.msdn.microsoft.com/c9eb3ba8-0c59-4944-9a62-6eee37294597. You get the intellisense support, debugging and even Unit Testing integration with Pester. In order to do this you need to use a PowerShell project. Usually I only need to edit my PowerShell scripts and I like to have the list of folders and files like you have with Visual Studio project or solution. There isn't a way in Visual Studio to open just a folder as you have in Sublime. The closest way of doing that is open File > Open > Web Site… Select File System and select the folder you want to open.

If you're developer and Visual Studio is your main IDE then this will be a nice addition to your Visual Studio tool set.

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.

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.