I am going to teach a one day seminar on programming to students grades 6-12 at Synergy.

Synergy is asummer experience programoffered by the DeGroote School of Businessat McMaster University for students in grades 5 -12. It affords students the opportunity to experience business as a field of study in a post-secondary setting.

I recently got to use OpsHub Visual Studio Online Migration Utility to help the client move from on premises TFS environment into the awesomeness of Visual Studio Online. OpsHub Visual Studio Online Migration Utility is actually pretty good and solid tool. The migration was very smooth and relatively painless. I thought I share some of the things I have come across when using VSO using OpsHub Visual Studio Online Migration Utility:

During the installation, you will be required to fill out the registration info. Please make sure that you have provided a valid email address since you will need a verification code to proceed with the installation that will be sent to the email address you provide during the install. Usually, it takes a couple of minutes for an email to come through. Check your Spam folder in case if the email was mislabeled by your spam filter

If you are using proxy servers to connect to the internet, you will need to do the following http://opshub.com/main/index.php/ovsomu-proxy to get the installer working. Please note that even if you follow the instructions, and even if you get passed the registration page to next page (Verify Email page), which to a normal person mean that the registration process was successful and that you should receive verification email, it does not necessarily mean that you will get an email. The reason for it could be that your proxy is blocking the installation wizard from sending the registration info to Opshub. Very frustrating. As a workaround, you can run the installation wizard on any other machine that is not going through the proxy, fill out the registration email, wait for an email, then use the verification code that you have received to install OpsHub Visual Studio Online Migration Utility on any other machine in your network. From what I can tell, verification code is not tied to machine that you're installing on in any way

If you have installed OpsHub Visual Studio Online Migration Utility while your machine was going through the proxy to get to the internet, and then managed to convinced your IT to allow you to bypass proxy, you will need to uninstall OpsHub Visual Studio Online Migration Utility, remove any changes you've made as per http://opshub.com/main/index.php/ovsomu-proxy and then reinstall OpsHub Visual Studio Online Migration Utility. Sounds silly, but it's true. By the way, I strongly recommend that you spent some time and convince your IT to allow the machine that is running OpsHub Visual Studio Online Migration Utility to bypass the proxy, it just makes things a lot easier. Especially when you start configuring the migrations.

Before you start configuring migrations, you will need to:

Pre-create empty team projects (with matching process templates) for the team projects that you will be migrating from on premises TFS

Add users to your Visual Studio Online account and grant them some permissions on the team projects. One of the steps in configuring the migrations is map local users to VSO users, so you'll need users to be in place before you start the migration

Add VSO account that you will be using to migrate to Project Collection Service Accounts group in VSO

Remember that you can migrate one project a time. You don't have to move the entire project collection from on premises to VSO

If you're migrating work items then you might have to deal with template discrepancies. Be patient.

OpsHub Visual Studio Online Migration Utility is provided by a company called OpsHub, Microsoft partner. Their support is pretty good. You can reach them via email ovsmy@opshub.com or via StackOverflow using hashtags #opshub and #visual-studio-online. Please keep in mind that the company is located in California, USA, and take into account the time difference when awaiting a response.

I have been asked if TFS 2013 Release Management allows you to schedule TFS releases. Yes, you can schedule TFS release. What I mean is TFS allows you to schedule the deployment time of the release during the acceptance step of the release path. It's that easy.

But what if you want to schedule release to happen on a regular basis, for example you would like to automatically deploy/release the latest code to the development environment every Monday/Wednesday/Friday nights. TFS 2013 Release Management does not really have that feature. Luckily, we have reach TFS API and PowerShell. So, here is a PowerShell script that triggers release of the last successful build with the build quality set to "Ready for Deployment" (obviously, you can use any other filter to get the build you want):

As you can see from the script, script first connects to TFS, finds the proper build definition, then looks for last successful and "Ready for Deployment" build, then uses ReleaseManagementBuild.exe to trigger the release for that build. Obviously, the script could be improved, for example, to include the exception handling, but it should enough to get you started.

Now that you have the script, you can use Windows Task Scheduler to trigger the release outside of the Release Management client. As often as you need it, whenever you feel like it.

As I was looking for API reference for TFS Release Management, I came across this useful link that I wanted to pass along. Visual Studio Online REST API Reference page (https://www.visualstudio.com/en-us/integrate/api/overview) includes API reference for TFS components like build, work item tracking, version control/GIT, load test, test management, shared services, etc. Basically, it includes reference for all existing API hooks for TFS/VSO.

I have also found this blog post (http://blogs.msdn.com/b/aseemb/archive/2014/12/23/how-to-program-against-release-management.aspx), which includes the API reference for TFS release management. It includes sample code that allows you to create a user, environment, release path, release definition, etc. Please note that release management (like build) is changing quite a bit in TFS 2015, so it's safe to assume that the API for build and release management will also be changing. Visual Studio Online REST API Reference page should have the latest changes, so just use it as a reference :)

If you haven't already seen it, look at the information on getting started with these APIs.

You are invited to join an online event on July 20th to learn about the new features and technologies coming with this release. No registration is required! Just follow the link and save the date on your calendar! There will be live Q&A session with the VS developers involved in building the app after the pre-recorded show video.

There have been occasions where I've wanted to create work items in bulk.

For example: Every time you create a User Story your team has several standard Tasks that need to be created. Write Test Cases, Execute test cases, Deploy to QA, etc. I don't want to manually go through dozens or work items adding the same set of work items as children to each one over and over.

Excel is a pretty good option, certainly faster than doing it one at a time via Team Explorer or the Web interface. In the past I have written C# applications to do this through the TFS API. This works great and is very easy to code.

I am always trying to force myself to get better with PowerShell, so I started searching for examples of calling the TFS API from PowerShell. This helped me piece together the parts I needed to solve this problem with PowerShell.

These were my requirements:

There are N Stories in TFS each one represents an existing report that needs to go through several stages of work.

We want 6 new Stories created as children of each Report Story so the work can be assigned to different teams in the organization then the individual teams can create their own tasks.

We don't want the Child Stories to all have the same title. That is fine when you see them in context of their parent like this:

Report 1

Report Attributes

Data Lineage

Gap Analysis

Report 2

Report Attributes

Data Lineage

Gap Analysis

However when you see the Report Attributes Story on its own it means very little.

Therefore I want was something like this:

Report 1

Report Attributes for Report 1

Data Lineage for Report 1

Gap Analysis for Report 1

Report 2

Report Attributes for Report 2

Data Lineage for Report 2

Gap Analysis for Report 2

Plus each sub story needs to have the same Area, Team and other attributes as its Parent Story

As you can see a simple cut and paste in Excel won't do, because I would still have to edit each work item to add the report name to the title and populate the fields from the parent that I want brought over.

Microsoft has released a DevOps self-assessment online tool that allows you to gauge your readiness in the 7 key DevOps practice areas. Complete the form below to step through the assessment and see your results including guidance on which areas to focus on next. Total time commitment is approximately 10 minutes. DevOps self-assessment tool can be found at http://devopsassessment.azurewebsites.net/

Click on Download agent link to download .zip file with build/release agent in it. Right click on downloaded .zip file, click on Properties and Unblock the files if it is blocked

Now the tricky part, the installation of build/release agent is essentially unzipping the file into a folder. Please make sure that you unzip the file into a folder that is not under your user profiles (for example, Downloads or Documents) or Program files folders, because this will cause UAC to kick in when build/release job will try to call to build/release agent. So, unzip folder somewhere like D:\BuildAgent\. Once you've unzipped the file into a folder, you have installed build/release agent. Now we need to configure it.

Open PowerShell (preferably as administrator), and browse to the folder where you unzipped the build/release agent

In the new TFS 2015/VSO build, you can save the output to the server or to the good old drop location. If you would like to use the drop location, you will need to remember to specify how you would like the output to be stored. What I mean is that you will have to specify in the build definition the folder structure you would like to create. For example, instead of \\servername\drop, you will need to specify \\servername\drop\$(Build.DefinitionName)\$(Build.BuildNumber)\

There are quite a few system/metadata variables in TFS 2015, but that will be another blog post.

UPDATE: There is now Publish Build Artifact action in new TFS Build that you should use to control where and how your build output is produced.

P.S. : If you're not using new TFS 2015/VSO build system, you should give it a try. It's awesome.