Developing Azure Functions in Visual Studio and Creating a Deployment Pipeline Using VSTS

Serverless computing has become a hot topic these days. It is providing you with paying only for the actual time your code is running and resources you are consuming without any worries about infrastructure. Azure functions let you build functions that can scale dynamically based on the needs, with a languages of your choice. When you install Visual Studio Azure Development workload you get templates for developing Azure Functions. Let’s look at how to create a simple Azure Function “Hello World” in Visual Studio and most importantly how to get your CI/CD pipeline ready within couple of minutes.

Finding Membership Information of a User/Group/Team in VSTS/TFS

Managing permissions of a VSTS/TFS sometimes become a nightmare specially if you have many teams groups etc. created in your account and in team projects. It is important to have a way to find group membership of an individual or group, so that you can analyze where the memberships are assigned in order to make required maintenance or change permission activities. Lets look at a command which can help you find that information quickly.

Controlling Octopus Releases with VSTS Release Management

You may be using Octopus deploy for your deployment automation pipeline needs while you are having your builds and work items managed in VSTS. It is a good idea to manage the Octopus release pipeline via VSTS release management so that you have the opportunity to use automated test execution and capturing of test results, as well as easily generate release notes using the VSTS work items, using feature rich tasks and automation test results views in VSTS release management. Let’s look at the important steps required to make VSTS release management to successfully utilize your existing Octopus deploy process steps.

Securing Release Definitions When Multiple Teams Work on a Single Team Project

We have explored “Securing Build Definitions When Multiple Teams Work on a Single Team Project” in a previous post. Now the folders to group release definitions and applying permissions to isolate each team’s release definitions is also a possibility in VSTS. As we discussed in the “Securing Build Definitions When Multiple Teams Work on a Single Team Project” it is important to create the Build/Release admins VSTS permission group for each of the teams in the team project. Using the same admins group and the team we can setup permissions for release definitions folders. Let’s look at the steps in detail.

Integrating VSTS Package Feed to Octopus

Octopus deploy is used by many organizations as their continuous deployment tool. You can send a package to Octopus deploy server via VSTS build or release step, using  “Push Packages to Octopus” task comes with VSTS Marketplace extension named Octopus integration. However, if you prefer to use VSTS Package Management to store your packages, you can now consume them in Octopus by integrating with the VSTS Package Management feed. Let’s look at how to setup Octopus to consume VSTS Package Management feed packages. (We have discussed how to use VSTS Package Management feed as artifact source in VSTS Release Management in a previous post “Using NuGet Packages as VSTS Release Artifact Source”)

Trigger Build Based on Label/Tag – VSTS/TFS

You might want to trigger a build for a team foundation version control (TFVC) Label applied previously or if you are using Git version control for a Tag. Git tags are quite nicely supported in TFS/VSTS web Interface, but Label in TFVC is still only manageable with the  Source Control explorer of Visual Studio. There is a user voice request to enable web experience for TFVC Labels, which you can also vote for . Let’s explore how to trigger build based on Tag or Label with VSTS/TFS.

Running UI Tests with Unified Agent

You needed to setup dedicated machines for testing when using Run Functional Tests and you had to execute, Deploy Test Agent step and Copy Files step as prerequisites. With the introduction of unified agent enabling build, deployment and testing using same agent, now it is possible to setup pool of machines as Test clients to cater multiple project needs. You can even deploy and test using the same agent if you wish to do so.  Unified agent support is available to run tests as multi-machine distributed execution. You do not require to execute copy files task as artifacts downloaded by the agent can be used for running tests. Let’s look at how to prepare a unified agent for running UI tests.

PS Script Get All Team Projects Listed as HTML–TFS/VSTS

You may want to sometimes satisfy the needs of your team, specially PMs, requesting already available information in document format. Some managers are lazy to go and explore (that's why they choose to be managers not techies) and they sometimes expect information to be delivered to their hands . List of Team projects in each collection can easily be seen on the TFS web interface or in VSTS in admin mode. But here is a PowerShell script to generate the same list as HTML file with link to the relevant team project, if someone requested you to have it as a separate document.

Build Definition as Code with YAML Builds

Build configuration as code and store it in version control was a request from some time back. It is great to have your build definition as code alongside your application source code. Microsoft has now released preview of YAML builds for this purpose to VSTS. Even though as of now it is limited to use with VSTS GIt and GitHub, version control (TFSVC not supported) to create CI builds, it is just the beginning of a new way to think about defining CI, CD pipelines and it will evolve into much greater levels in the future. Let’s get a basic YAML build done to understand what it is.

Mistake in .sln Can Cause NuGet Restore Task in Build to Fail and Hide the Real Issue

NuGet packages are very commonly used in VS Development. Using build VSTS task NuGet Restore is general practice of downloading packages while doing the automated builds. Today suddenly a team ran into the same issue described here https://developercommunity.visualstudio.com/content/problem/97737/error-da-toolnuget400x64nugetexe-failed-with-retur.html. Let’s have a look at the real issue caused this error in this particular teams’ instance and how it was found and resolved.

Code Review with Git in Team Services

Code Review plays important part in software development as it helps to identify issues that may be overlooked. Reviews on code improve overall quality of the delivered software, and reviews are done in different ways by the teams, at times using pair programming, peer review and formal inspection of code by team leads etc. Team Services Git  version control now facilitates Code Review, via pull requests.

Business Rules for Work Items in Team Services

For inherited process model in VSTS, you can use Custom Rules to define rules that can clear the value of a field, copy a value into a field, and apply values based on dependencies between different fields' etc. You can define actions against conditions using custom rules. This provide you the flexibility in VSTS to go beyond the level of setting a default value or making a field required. To customize work items in an existing team project of Hosted XML model for VSTS, or on-premises TFS, you have to customize, downloaded process template or individual work item XML files (using witadmin tool) respectively. Differences between process models are described here.

Run xUnit Unit Tests for (dnx)ASP.Net 5 with VS Team Services Build

To run the xUnit unit tests developed for ASP.Net 5 (ASP.Net Core 1.0 now), you need to setup a powershell step/task. Setting up a build with VS Team Services, for ASP.Net 5 is explained here.
First thing we need is a powershell script, which can runt xUnit tests, in VS Team Services build. (Hardcoded paths and project names in the script)

Set-ExecutionPolicy unrestricted -Scope CurrentUser -Force

$VerbosePreference = "continue"
$ErrorActionPreference = "Continue"
     
&{$Branch='dev';iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/aspnet/Home/dev/dnvminstall.ps1'))}
$globalJson = Get-Content -Path $PSScriptRoot\..\..\EventBooking\global.json -Raw -ErrorAction Ignore | ConvertFrom-Json -ErrorAction Ignore
 
if($globalJson)
{
    $dnxVersion = $globalJson.sdk.version
}
else
{
    Write-Warning "Unable to locate global.json to determine using 'latest'"
    $dnxVersion = "latest"
}
 
& $env:USERPROFILE\.dnx\bin\dnvm install $dnxVersion -Persistent
 
$dnxRuntimePath = "$($env:USERPROFILE)\.dnx\runtimes\dnx-clr-win-x86.$dnxVersion"

dnx -p $PSScriptRoot\..\..\EventBooking\BookMyEvents.UnitTests test 

Check this script in.
We have to make sure test results are available to publish in the build. for that we can change the test project .json to create a results xml.
Next add a powershell script task/step to the build. Set the script to execute and let it continue on error, to make sure, it will not break the build on a test failure.
To publish the results, use “Publish Test Results” step. Set the test results xml file name specified in the project .json, for the results files. Select the Test result format as XUnit.
Once a build queues it executes the test and publish the results.

When there are multiple tests running in the build, a detailed test report helps to identify which tests fail.

ASP.Net 5 (RC1 Update1) Deploy to Azure Website with Visual Studio Team Services Release

How to setup a build with Visual Studio Team Services, for building ASP.Net 5 (ASP.Net Core 1.0 now) is explained in here. Let’s look at steps necessary to create a release pipeline to deploy, ASP.Net 5 website to Azure, with VS Team Service Release.
First requirement is to develop a poweshell script, whcih is capable of deploying, the built ASP.Net package to Azure. Information on how to write such script is available here.
Script

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

param($websiteName, $packOutput) $website = Get-AzureWebsite -Name $websiteName # get the scm url to use with MSDeploy. By default this will be the second in the array $msdeployurl = $website.EnabledHostNames[1] $publishProperties = @{'WebPublishMethod'='MSDeploy'; 'MSDeployServiceUrl'=$msdeployurl; 'DeployIisAppPath'=$website.Name; 'Username'=$website.PublishingUsername; 'Password'=$website.PublishingPassword} $publishScript = "${env:ProgramFiles(x86)}\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\Publish\Scripts\default-publish.ps1" . $publishScript -publishProperties $publishProperties -packOutput $packOutput

Add this script to version control.
Modify our release build in previous blog to copy deploy script to build output.


Let’s create Azure Web Application as the target.

Site created and ready.
In Visual Studio Team Services, Release tab create a new empty Release Definition.

To link the release definition to the build created earlier, click on Link to a build definition.
Select the build definition and link it to release definition.
Rename the Default Environment to DevInt(Or what ever name you prefer).
In the DevInt environment create a configuratoin varibale to hold the Azure web site name.

It is possible to set approvers to the stage. So that an approval requires to get the build deploy to the stage/environment DevInt. Let’s set it to autimated and after deployment set a manual approval, to allo get it approved before deploying to next stage/enviornment in the pipeline.

In the release definition add a Azure Powershell task to execute the deployment script. Azure subscription how to link to VS Team Services account can be found here. Set the deployment script to Azure Powershell release task in Dev Int

For Web Site Name environment variable can be used in the cript arguments.
-websiteName $(WebSiteName) -packOutput $(System.DefaultWorkingDirectory)\Event.Rel\EventRelOutput\
Eventhough trigger can be set to continuous deployment like below.
Let’s leave trigger to manua for the time being.
Now you can trigger a release with the any successful build output you have using the release definition.


Build get deloyed to DevInt environment and wait for the post deployment approval.
DevInt environment site is running now.
An Improvement to the build number can be made like following.
Release name format also can be set to use build number for it to be more meaningful.
Release No $(Build.DefinitionName)-$(Build.BuildNumber)-R-$(rev:r)
Multiple environements in the pipeline can be configured.
Deployement logs in the pipeline. You can view these logs, while a release is happening.
Release history can be viewed.
Release definition change history is available as well t diagnose any issue which might have ocuured with a change to the definition.
Difference between two defnitions.

New release managment services with VS Team Services is awsome, and let’s explore more in the coming posts.

Part 2 Deploy ASP.Net 4 Web Site - Deploying to Azure Web Site with Visual Studio Team Services Release

We have successfully built and produce downloadble build output in the Part 1 Build ASP.Net 4 Web Site. Let’s look at how we can setup a Release Pipeline with Visual Studio Team Services Release Management, to deploy this web site as an Azure Web Application.
Click green + to create a new release definition.
Select Azure WebSite deployment and click Ok in the dialog box.
This will create an environment with Azure Web App Deployment task. Rename the environment added to let’s say DevInt.
In the Artifacts tab of the release definition, click on Link an artifact source.
Select the build we have created in Part1.

In Azure Web App Deployment task set the parameters as shown below.
To link Azure Subscription to your VS Team Services Team Project follow the instructions here. Web App Name is the Azure Web App Name. Use the App Service Location as the Web App Location.

Select Deploy Package from linked artifact. How to publish build artifact is explained in Part1.
Trigger can be set to Continuous Deployment so that new artifact availability will trigger a deployment.
Approvers can be assigned but let’s keep it automated.

Let’s trigger a new build using build definition we have created in Part1.

Once the build done release automatically get triggered and get completed.


Site is getting deployed to Azure Web App.