Create New Team Project TFS 2015

Most of the Admin features are available for TFS 2015 through the Browser Console. These can be managed using the URL:

http://servername:8080/tfs/_admin

If you need to create a new Team Project under an existing Collection, you need to be part of the Project Collection Administrators Group for that collection in TFS 2015.

The URL to access that is :

http://servername:8080/tfs/collectionname/_admin/_security/?_a=members

You can add Windows user or group or TFS group.

To create a New Team Project, go to the following URL:

http://servername:8080/tfs/collectionname/_admin

and click on New Team Project and fill out the required details and click on Create Project.

This will reflect in the Source Control Explorer in Visual Studio where you can then start creating branches.

How to give Use permissions for Build queues TFS 2015

If you have access to a Project Collection in TFS 2015 but still not able to queue builds, then you are required to be added to the Project Collection Build Administrators group.

The error message would be as below:

500: Access Denied: <username> needs Use permissions for queue <queuename> to perform this action.


To give access, when you’re in the Source Control Explorer in Visual Studio and connected to the required collection, click on the Team -> Team Project Collection settings -> Group Membership.

Under the Security Tab, add the User or group under the Project Collection Build Administrators group as shown below:

Connect to a Project in TFS Visual Studio

On the Team Explorer, Click on the icon highlighted in the screen-shot below and then click on Manage Connections. Select “Connect to a Project” from the Menu.

Manage Connections is also available under the Team menu in Visual Studio.

If your Team Foundation Server is not already added then click on the “Add TFS Server” link and you’ll need to enter the TFS URL and click on Add.

You may need to enter your credentials in the pop-up window. The list below shows the Test Project, select it and click on Connect.

Finally you can map the TFS Server path to your Workspace Project i.e. Physical folder on your machine as shown below:

Deploy WebAPI with TFS Build Definition

To deploy and Publish a WebAPI or MVC application, these 2 steps should work most of the time:

  1. Visual Studio Build
  2. Publish Build Artifacts

If you right-click on your WebAPI Project, go to “Package/Publish Web” tab and check the Items to deploy drop-down, the default value selected is:
Only files needed to run this application

The below solution produces the same output as when you build the WebAPI in Visual Studio.

This is the cue, that let me find the solution to build my WebAPI Project. The WebAPI Project consists of multiple Class Libraries with Business and DAL layers as well.

Follow the steps as below:

  • Add /p:DeployOnBuild=true /p:OutDir=”$(build.artifactstagingdirectory)\” arguments in Visual Studio Build step:
  • Change “Path to Publish” of Publish Build Artifacts task to $(build.artifactstagingdirectory)\_PublishedWebsites\ProjectName:

I’ve written another post on Creating Build Definition here.

Set Project Build Order in Visual Studio

In order to set the Build order for your Solution, right-click on the Solution in Solution Explorer and Select Project Build Order:

Your Project Dependencies should be set correctly which is used to determine the Build order by Visual Studio.

The image below shows the Project references added in the Business layer to determine that the DTO and Persistence Projects should be built first before the Business layer Project.

The Project Build order will make sure the required dlls are available for the Api to compile correctly.

Now give your car batteries a good re-conditioning they need. Click here to know more.

Join Armoney for best Cryptocurrency trading experience. Trade from anywhere, anytime!

Continuous Deployment execute database scripts with TFS

In another post, we’ve learned how we can use a Build definition and Release Management in a CI/CD pipeline. Please go through the articles if you need more information on these topics.

In this post, I’ll explain how we can use Release Definition to execute database scripts as part of the continuous deployment strategy. We will add a task to execute PowerShell script to achieve this.

Create Release definition

The task to be added is PowerShell under Utility. This task should be added before the Application files are deployed in the CD pipeline.

Create a Release definition for your Release pipeline as shown below, the path for the PowerShell script should be a shared path and the database Server is accessible.

Add the below code snippet to the PowerShell script. The script should be modified as per the requirement.

$localScriptRoot = "C:\Scripts"
$Server = "dbserver"
$scripts = Get-ChildItem $localScriptRoot | Where-Object {$_.Extension -eq ".sql"} | Sort-Object -Property Name
$qt = 0
foreach ($s in $scripts)
    {
        Write-Host "Running Script : " $s.Name -BackgroundColor DarkGreen -ForegroundColor White
        $script = $s.FullName	
        Invoke-Sqlcmd -ServerInstance $Server -InputFile $script -username "TFSBuildUser" -password "****" -querytimeout $qt
    }
Write-Verbose "scripts executed successfully" -verbose

The scripts to be executed are present at the location C:\Scripts with extension “.sql”. The password can be also passed as an argument to the PowerShell script and added to the Release Definition secret variable.

Use the Triggers tab to link to the required Build definition of your Project so that the Release definition is integrated with the Build pipeline. The linking can also be done using the Artifacts tab.

You can setup multiple environments using this strategy like Dev, POC and Production.

Build Web Application with TFS

The msbuild capability of TFS 2015 or 2017 agent helps build a Web Application using MSBuild Arguments. The Visual Studio Build task is required to pass the msbuild arguments along with the path of the solution file to build.

Fill the msbuild arguments with:

/p:DeployOnBuild=true /p:PublishProfile=<PublishProfileName>

Make sure the Publish profile is checked-in. It is an xml file which is used to save the Publish settings for a Project which includes the Path to Publish and the Deployment mode which can be Debug/Release. This file is found under the Profiles folder of the Project. Also, make sure in your Build Publish Profile, the option Precompile during publishing is checked.

BuildStep1

You can also use the following MSBuild arguments to Publish the Web Application build into the directory as specified in the publishUrl argument as below:

/p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:DeleteExistingFiles=True /p:publishUrl=$(build.artifactstagingdirectory)\Deployment\$(BuildConfiguration)

The artifactstagingdirectory is the “a” folder on the Agent for the Project Collection Id under which the Project is built. This is where the files are copied after the Project is built from the Source “s” folder.

BuildConfiguration variable under the General Tab contains Debug/Release.

e.g. C:\TFSAgent\agent\_work\<Id>\a\bin\Deployment\Release\

If the MSBuild arguments are not specified, the artifacts folder will not contain only the code files and not the build files. Save the Build definition and queue the build to view the results.

I’ve written another post on Creating Build Definition here. Another way that might work for you is a post about Publishing WebAPI or MVC application here.

Pre-build versioning with PowerShell script and TFS Build

There are a lot of scenarios where the PowerShell script requires to be run as a Build task in your Build definition. In of the cases, we had a requirement to change version attribute in the AssemblyInfo.cs files in all Projects of our solution. The version number required to be in the format “1.0.0.”. This version number should be visible in the exe properties after installation.

To achieve this, I created a PowerShell script, which recursively found all the AssemblyInfo.cs files in all Projects, checking for the Attribute pattern and replace it.

Create a PowerShell script file in the ISE and copy the following code:

Define the Params:

Param
(
[Parameter(Mandatory=$true)]
[string]$productVersion
)

$YYYY = (Get-Date).year
$SrcPath = $env:BUILD_SOURCESDIRECTORY

$AllVersionFiles = Get-ChildItem $SrcPath AssemblyInfo.cs -recurse
$versions = $productVersion.Split('.')
$major = $versions[0]
$minor = $versions[1]
$patch = $versions[2]
$build = $versions[3]

$assemblyVersion = "$major.$minor.$patch.$build"
$assemblyFileVersion = "$major.$minor.$patch.$build"
$assemblyInformationalVersion = "$major.$minor.$patch.$build"

Replace the Assembly attributes:

foreach ($file in $AllVersionFiles)
{

(Get-Content $file.FullName) |
%{$_ -replace 'AssemblyDescription\(""\)', "AssemblyDescription(""assembly built by TFS Build $productVersion"")" } |
%{$_ -replace 'AssemblyVersion\("[0-9]+(\.([0-9]+|\*)){1,3}"\)', "AssemblyVersion(""$assemblyVersion"")" } |
%{$_ -replace 'AssemblyFileVersion\("[0-9]+(\.([0-9]+|\*)){1,3}"\)', "AssemblyFileVersion(""$assemblyFileVersion"")" } |
%{$_ -replace 'AssemblyInformationalVersion\("[0-9]+(\.([0-9]+|\*)){1,3}"\)', "AssemblyInformationalVersion(""$assemblyInformationalVersion"")" } |
Set-Content $file.FullName -Force

}

The script requires to following parameters which requires to be passed in the Build task:

PSVersion1

The code should be checked in to TFS and mapped to a local folder from the Repository tab so it can be downloaded on to the Agent machine locally.

PSVersion12

This PowerShell build step should be the first step in your Build definition before the Visual Studio Build task so that the version changes can take place as soon as the code is fetched on the TFS Agent work folder.

Tip: Make sure your AssemblyInfo.cs files has the above attributes which you’re replacing with the PS Script in the specified format else some dlls may miss out on the updated versions.

Change Password for TFS Build Service Account

The TFS Agent for 2015 or 2017 versions is a Windows Server machine that hosts the Service that allows to run Build and Release definitions for your code as part of the DevOps Process. It can run as a Windows Service and can be found by the name VSO Agent in the Services Snap-in. It uses a domain account to run the Windows Service which can be seen under the LogOn properties of the Service.

It runs VSOAgent.exe behind the scenes which is kept in the Agent folder configured for that TFS Agent e.g.

C:\TFSAgent\agent\Agent\VSOAgent.exe

If at any point you require to change the Windows Service account details that was configured earlier due to may be a password change, the following command may help you.

Please note that Password should not be changed from the Services Snap-in as it may cause the Agent Service to break.

  1. Open Command Prompt in Administrator mode.
  2. CD to the directory e.g. as mentioned above C:\TFSAgent\agent\ . Make sure you’re one level above the folder where the VSOAgent.exe is placed else it’ll give error.
  3. Run the following command: .\Agent\VSOAgent.exe /ChangePassword
  4. Fill in the new Credentials as Prompted.
  5. Restart the Service VSO Agent from the Services Snap-in.

The Agent should now be running with the new Service account.

Release Management with TFS

Release Management is a service in VSTS Azure pipelines and TFS on-premise and an essential element of DevOps that helps you continuously deliver software. We can fully automate the testing and delivery of your software in multiple environments all the way to production, or set up semi-automated processes with approvals and on-demand deployments.

CI Build

Release definition defines the end-to-end release process for an application to be deployed across various environments.

You define the release process using environments, and restrict deployments into or out of an environment using approvals. You define the automation in each environment using phases and tasks. You use variables to generalize your automation and triggers to control when the deployments should be kicked off automatically.

You can create a deployment model on the basis of how you manually deliver the builds using build definition for different environments.

The below Release Definition shows different steps using PowerShell scripts that are modeled basis the manual process created for deployment.

Release definition

 

Creating a Release definition

Configure your environment:

  • Give the environment a meaningful name by clicking into the Default Environment name provided and enter one of your own e.g. DEV, QA, PRODUCTION.
  • Click on the ellipsis next to the environment name and select Deployment conditions…

rd1

 

Deployment Conditions

rd2

This is where we set up how we want our deployment to be triggered. It is here that we define what triggers the deployment of our release.

  • No automated deployment– deployment of the build artifacts will need to be undertaken manually with no automation
  • After release creation– this will deploy the build artifacts to the specified environment every time a new release is created i.e. Continuous Delivery.
  • After successful deployment on another environment– this will deploy the build artefacts to an environment after they have been deployed to another environment e.g. after every successful deployment to the STAGING environment deploy the build artefacts immediately to the QA environment

Use the first option if you are deploying to a production environment i.e. make the deployments to your production environment a manual exercise. Use the second option if you are deploying to a development testing environment as part of a Continuous Delivery pipeline. Use the last option if you want to push your deployments between different testing environments.

Approvals

You may setup Approvals before the deployment to a particular environment using the Approvals Tab.

rd3

 

Configure a Queue and set demands

The demands may be System defined like “DotNetFramework” or you can set yourself like selecting Agent name.

rd4

 

General Tab

rd5

 

After configuring your environment, the next step would be to add task(s) which will be invoked when we want to deploy our build artifacts to the specified environment. The deployment task is the action that we want to happen when we invoke a deployment e.g. running a PowerShell script to start/stop App Pool, running database scripts, deploy the build on to a Virtual Machine or Azure instance.

Create Release

Create Release and select the build for which you would like to create a release in Dev environment and click on Create as shown below:

rd6

The successful build selected above will trigger the Automated Deployments based on the selections made for each environment.