The first extension made by me, “Chamindac.vsts.release.task.download-artifacts” is now public in VSTS Marketplace.
Getting started details can be found in this post “VSTS Release Task – Download Artifacts – Filter for Given Artifact Name(s)”
Why this extension is required is explained in post “Multiple Build Artifacts–TFS 2015/VSTS Builds”.
Source code for this extension is available in Github.
This extension “Chamindac.vsts.release.task.download-artifacts” for VSTS and TFS 2015.2.1 upwards, can be used to filter for build artifacts by name, and download only required artifact(s), to the release agent machine. The requirement for this extension is explained in post “Multiple Build Artifacts–TFS 2015/VSTS Builds”. Source code for this extension is available in Github.
Extension “Chamindac.vsts.release.task.download-artifacts” can be downloaded/installed from VSTS Marketplace. To install to VS Team Services click on install, or download for on-premise TFS 2015 (TFS 2015.2.1 upwards supported).
Once installed, in release definition tasks a new task will be available under Utilities.
Always add this task as first task of the release environment and make sure the environment is set to skip artifact download.
The tasks comes with default filled values to behave as normal Download artifacts.
Build artifact names should be specified in ; separated syntax. Or it can be a single artifact name. Or * for all Artifacts.
Artifact destination is set default to behave as similar to, out of the box, build artifact download.
This task will filter the build artifacts with given names and download only the specified ones.
It is possible to create multiple drops in a new TFS 2015 build or in VS Team Services build. This is useful when you want to do a single build but want to have separate drops(artifacts), for different deployment purposes.
One such example is
In this situation the deployment happens in a web hosting server and the release agent used there is not going to run the test automations. The agent running test automations will be a separate agent, configured in test client(s), administering machine.
Example 2
Same as above it could be two different release agents configured in two different machines, which does not need others build artifact.
But with the above requirement in mind, it is always advisable to build all components, in a single build to make sure the version is properly built and in sync.
Is it possible to have multiple build artifacts in a single build?
Yes. Let’s look at how we can do that. It can be done by, adding more publish or copy publish tasks to your build definition.
One drop can be in File Share while other can be in Server (Can have both in File Share or both in Server as well).
When a build is done with the above settings, two build artifacts get created for the build.
Next Challenge: Download the only required artifact to the relevant release agent.
With the out of the box functionality in TFS 2015.3 or with VS Team Services currently this is not possible. It does not allow to filter for a given artifact when downloading. Only option is skip download (no artifacts download) or download all artifacts.
When the above skip download is unchecked all artifacts get downloaded to agent. No filtering possible.
How to download only required artifact?
A new extension with capability to filter for named build artifacts and download only them is created. The code is available in here. The extension “Chamindac.vsts.release.task.download-artifacts” is available in VSTS Marketplace. Usage of extension is explained in this post “VSTS Release Task – Download Artifacts – Filter for Given Artifact Name(s)”
To deploy a .dacpac to Azure DB with VS Team Services you can use “Azure SQL Database Deployment” task.
Setup either Azure Classic service endpoint or Azure RM Service endpoint in the, Team Services team project.
In a build or release definition add an “Azure SQL Database Deployment” task. Both classic and RM based setting up shown below.
Provide
or you have the option of setting firewall rule like below to get it working. Since you are deleting rule once done this is ok. But it is not that secure to allow all IPs like below.
This can successfully deploy the .dacpac file to Azure DB using VS Team Services Release.
To configure an on-premise test client machines with Visual Studio Team services release follow the below steps.
Diagram 01
1. Setup test client machine with WinRM if not already installed. (WinRM is automatically installed with all currently-supported versions of the Windows operating system.)
2. Enable PowerShell remoting in the test client machine.
Enable-PSRemoting
3. Add test client machines in machines tab and create machine group. This is available in VSTS Test tab as of now.
Do not worry about the warning that it will be removed. It will just be moved under release tab will be a more enhanced feature. The link specified in the warning message clearly explains it.
When adding machines you can use machine FQDN. Visual Studio Team Services need no direct access to these test client machines. Having one release agent setup in the domain, which have access to the test client machines, as shown in Diagram 01, would be sufficient. Release agent machine can access the test client machines with domain credentials since it is inside the on-premise domain.
4. Create a release definition to create test client, and set to use an agent in the on premise domain. Configure on-premise agent for Visual Studio Team Services explained here.
5. Add Visual Studio Test Agent Deployment task to release definition.
Specify the machine group name in Machines, created in step 3. Agent configuration user can be different from the user name provided for accessing the machines in machine group defined (same user used here). Agent configuration user is used to configure test agent, and test agent will run as this user. Check Interactive Process if Coded UI test needs to be run on the test clients.
This will auto deploy test agents to on-premise test clients in the machine group, from VS Team Services release.
Next post will explain how to run a coded UI test with the deployed agent.
Agent queue in a TFS 2015 build definition will not be listed for team project administrator, even though he can save a build definition.
To make agent pool available for the user creating a release or build definition in TFS 2015, you have to add to Agent queue users in the team project collection agent queues, “Agent Queue Users” role.
This will make the queue available to the build/release definitions. But this will enable access to all agent queues.
This happens because when you add to, it gets added to All queues level when you add as shown above.
To restrict to a given agent remove from “Agent Queue Users” role, of the collection and add only to the relevant agent queue.
This will make the user added only to the relevant queue, Agent Queue Users. Not to the collection role.
Only the permission granted agent queue is available for the user.
If you install additional software in build server, or in a target server setup as a release server with build/release agent TFS 2015, you might run into the same issues specified below, which can be solved very easily.
The requirement
Need to run python and sphinx to generate documentation in the build server with the project.
The Issue
2016-06-28T08:56:24.4848312Z ##[error]The system cannot find the file specified.
2016-06-28T08:56:24.5316991Z The 'sphinx-build' command was not found. Make sure you have Sphinx
2016-06-28T08:56:24.5316991Z installed, then set the SPHINXBUILD environment variable to point
2016-06-28T08:56:24.5316991Z to the full path of the 'sphinx-build' executable. Alternatively you
2016-06-28T08:56:24.5316991Z may add the Sphinx directory to PATH.
2016-06-28T08:56:24.5316991Z If you don't have Sphinx installed, grab it from
2016-06-28T08:56:24.5316991Z http://sphinx-doc.org/
Checked environment variables for the build agent user and all were fine. All required python environment variables were there.
But when printed the path in the powershell script running the command to generate help, it seems environment variable path, were not having python paths.
The fix
It is just need a restart to build agents to reload environment variables.
This was an easy fix, but many times it can be missed, and would waste time investigating many other options.
