I was recently having trouble generating some Release Notes for a current project that is using Visual Studio Online Visual Studio Team Services. With Git as our backing source control system there didn’t seem to be an easy way to see what Work Items were going into a release. Thankfully we are associating Work Items with commits which makes the following Powershell script work.
Passing in our current release branch, and our previous release branch we can isolate the new commits and then parse their commit messages looking for the “Related Work Items:” text that Visual Studio appends to commits. Once we have those WorkItem ids we can use the TFS api to get some info about them and create some release notes.
You can find the script on GitHub.
MVPDays is a series of one day events that focuses on content for IT and Dev Professionals sharing their knowledge allowing local communities to learn more and advance their skills based on real world experiences. The majority of the sessions are Content will focus on the following topics:
- Cloud
- IT PRO
- SharePoint / Office 365
- Development
It will be held in the following cities:
You're welcome.
| Join Live Q&As and interact with the architects and engineers who are building the latest features. |
| Great blog for Universal Windows Platform (UWP) devs to understand .NET Native |
| The latest Windows 10 developer training contents |
| How Microsoft Edge and Internet Explorer 11 on Windows 10 work better together in the Enterprise |
| Download any Visual Studio skus, including VS 2015 |
| All the info developers may need to write apps |
|
|
|
|
| Great site to get online courses on Windows 10 |
| Another great online resource for Windows 10 related videos |
I recently had an interesting experiencing writing post build PowerShell script for a client. The client wanted to check in certain files into source control after the build is finished. Sounds easy, right? You can use either good old tf.exe command line utility from Visual Studio command tools. Or, you can use something more current like PowerShell to write a simple script that will check in pending changes for you. The problem is that the client also wanted to associate work items with the check in. Not a big deal, right? Well, apparently it is a big deal. You cannot associate work item with the check in using tf.exe command tool. And, what's even stranger, I could not find a way to associate work item with the check in using PowerShell. I got stuck with figuring out how to make WorkItemCheckinInfo[] parameter in Workspace.Checkin method to work properly.
This is how I learned that apparently you can associate work item with TFS check in, but you have to use tf.exe command from Team Explorer Everywhere. Apparently, even though the names are the same, those are very different command line utilities. When you use tf.exe from Team Explorer Everywhere, you can associate work item with the check in using a simple command:
tf checkin ItemSpec -associate:WorkItemIds
It's that easy. I just wish –associate option was available in common tf.exe command from Visual Studio command tools. I would also wish that those two seemingly identical tf.exe commands would actually do the same thing (the same way), or at least that those commands would have different names to avoid the confusion. By the way, there are also other differences between those two commands with the same names. You can get them form the links provided in the post. I'm too upset to list myself L
Here is a bunch of links to resources that will help you get up to speed on what's new for developing Windows 10 applications.
Want to download Visual Studio SKU's including VS 2015 click here
Everything you needed to know to write applications using MS Tools
Windows 10 and what's new
Get Started
Design
Develop
Publish
Want to take Microsoft Virtual Academy (MVA) Windows 10 Courses click here
Channel 9 has some great windows 10 related videos here
I have started a new user group with the focus on Enterprise DevOps. DevOps is getting significant attention in the industry. Many organizations don't understand what DevOps is, how to adopt DevOps practices effectively within the organization, and are not aware of what DevOps tools to use. Toronto Enterprise DevOps User Group is focused on applying DevOps practices in the enterprise environment. This group is for people in the Greater Toronto Area who are interested in continuous deployment/integration, release management, infrastructure as code, change/configuration management, load testing & auto-scale, performance/availability monitoring, capacity management, automated testing, automated environment provisioning/de-provisioning, self service environments, automated recovery (rollback & roll-Forward), and many more of constantly evolving DevOps practices. Every level of experience is welcome, all we ask is that you come with an open mind and are excited to share your knowledge.
The first meeting is on September 10th, 2015. We'll start with a discussion of What is DevOps? DevOps is a term for a group of concepts that, while not all new, has catalyzed into a movement and is rapidly spreading throughout the technical community. Like any new and popular term, people have somewhat confused and sometimes contradictory impressions of what it is. Is it "Quality" or "Agile,"? Well, DevOps is a large enough concept that it requires some nuance to fully understand. DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through to the development process to production support. We will cover what DevOps is and is not during our first user group meeting.
Visit our website for more info. See you there.
Next week I will be going back to school. Well sort of.
I am going to teach a one day seminar on programming to students grades 6-12 at Synergy.
Synergy is a
summer experience program
offered by the DeGroote School of Business
at 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'm teaching the class using Python and Visual Studio.
Should be a lot of fun.
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:
That's all.
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):
param
(
[string] $tfsCollectionPath = "http://SERVERNAME:8080/tfs/COLLECTIONNAME",
[string] $tfsProjectName = "PROJECTNAME",
[string] $buildDefinitionName = "BUILDDEFINITIONNAME",
[string] $releaseTemplate = "RELEASETEMPLATENAME"
)
# Clear Output Pane
clear
# Enforce coding rules
Set-StrictMode -version 2.0
# Loads Windows PowerShell snap-in if not already loaded
if ( (Get-PSSnapin -Name Microsoft.TeamFoundation.PowerShell -ErrorAction SilentlyContinue) -eq $null )
{
Add-PSSnapin Microsoft.TeamFoundation.PowerShell
}
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.Common")
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.Client")
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.Build.Common")
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.Build.Client")
[Microsoft.TeamFoundation.Client.TfsTeamProjectCollection] $tfs = get-tfsserver $tfsCollectionPath
$tfsCollection = New-Object -TypeName Microsoft.TeamFoundation.Client.TfsTeamProjectCollection -ArgumentList $tfsCollectionPath
$server = new-object Microsoft.TeamFoundation.Client.TfsTeamProjectCollection(New-Object Uri($tfsCollectionPath))
$buildServer = $server.GetService([Microsoft.TeamFoundation.Build.Client.IBuildServer])
$buildDetail = $buildServer.QueryBuilds($tfsProjectName, $buildDefinitionName)
$foundBuilds = $buildDetail | where {($_.Quality -eq "Ready for Deployment") -and ($_.Status -eq "Succeeded")} #| sort $_.BuildNumber
if ($foundBuilds -eq $null)
{
Write-Host "No builds found"
}
else
{
#$foundBuilds = $build | select BuildNumber, SourceGetVersion, Quality, DropLocation
$LastReadyForDeploymentBuildNumber = $foundBuilds[-1].BuildNumber
$LastReadyForDeploymentBuildDropLocation = $foundBuilds[-1].DropLocation
Write-Host "Triggering build " $LastReadyForDeploymentBuild
&"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Release Management\bin\ReleaseManagementBuild.exe" release -rt $releaseTemplate -pl $LastReadyForDeploymentBuildDropLocation
}
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.