TFS 2017 Update 1 Commit Links Not Working

I am in the process of migrating GIT repos into TFS 2017 Update 1.  During the process I wanted to learn how you could link commits to work items.  It seemed fairly easy to just add #45 where 45 is the work item ID, in the commit message or via Visual Studio change linking.  Tried it a couple of times and the links were not being created.  It would only create them if I did it in the web using the link options in the work item under Development.

Linking via the web UI

I just could not figure out why the linking wasn't working.  Trying in Team Services there was no issue.  Then it got me thinking.  In Team Services I had just created an empty repo and added some files.   In trying that with my on premise installation that also worked and links showed up.

The Bug

In conclusion the bug exists when you import an existing repo using the TFS 2017 import feature.

If you create an empty repo in TFS and add your local repo and push it up to TFS then you are fine (following the Microsoft instructions they provide in the empty repo.)

Merging GitFlow and Pull Requests Together into One Process - Part 1

Recently I was challenged with coming up with a process that enabled the use of GitFlow and Pull Requests.  We were using Jira and Stash/Bitbucket with Visual Studio and SourceTree or command line locally.

Initially this was working fine until an additional requirement was added that only merges via Pull Requests were to be allowed for getting work on the Develop branch.  Because of the permission change you could no longer Finish Your feature and push your merged changes from your local develop branch up to the origin.  You would get a nice permission denied message.  I search high and low and could not find anything out there with a solution.

This is the process I came up with to manage feature work.  I will have some additional posts on managing work for Releases and Hotfix branches.

1. Start feature branch from your JIRA ticket.
1. Leave as a Feature branch type
2. Name of branch must be JIRA ticket (CHI-7)
3. This is equivalent to GitFlow Start Feature
2. Checkout this new feature branch locally
1. Assumes you have already checked out Master and Develop branches for this repository
2. Assumes you have initialized GitFlow locally for this repository (after checkout of Master AND Develop)
3. Commit changes to feature and push to the origin
4. Create pull request for feature to develop within Jira
1. Optionally you can do it in Bitbucket or in Step 3 as part of the commit (see options in SourceTree Commit)
5. Another person performs code review
1. After it meets their approval they will Approve the pull request in BitBucket
2. They will not perform the merge.  This is left to the person who initiated the pull request.
6. Before performing the Merge in BitBucket do a Finish Feature in SourceTree.
1. The goal is to only merge to Develop and delete your local branch
2. Don't do it via Visual Studio or Command line as it will delete the remote feature branch and the pull request will be cancelled. 
3. In VS there is a checkbox to delete remote feature branch so just don't check it.
7. Merge pull request in BitBucket
1. Check option to delete source branch after merge
2. The feature branch will be cleaned up on the origin only
8. Cleanup local repo
1. In SourceTree on Develop you will have your commit still.  Since you committed in BitBucket in step 7 we need to gracefully cleanup your local workspace
2. If you try to push you will get denied since this commit is not via a pull request or saying you can't push because you don't have latest from origin/remote
3. Do a Pull and check Rebase instead of merge
4. This will sync local with remote and the FEATURE WILL BE FINISHED!

The process in visual form.

Let me know if you have any questions around it!

Getting Your Precompiled Web Site to the TFS Build Drop Location

I have been working on precompiling a .NET web application so that our security vulnerability company could scan it for issues.  The dev team said that the precompiled web app could also be deployed to production.  With that said I have been working on replacing the existing build process with one using the precompiled version.

After some searching this was the best solution I could find to get it to precompile on my build machine.  I created a new publish profile that looked pretty much like the example and setup the MSBuild parameters in my build definition.  This worked great however when I looked in my network share where the build output is copied to it was missing.

Looking in the src location on the build machine I found the PublishDirectory where the precompiled site lived.  Since we specified $(MSBuildProjectDirectory) that is exactly where it placed the output.

Upon further research I tried this property and  it worked.  It is TF_BUILD_DROPLOCATION.  Other environment variables for TFS can be found here

The final publish profile then looks like this:

<?xml version="1.0" encoding="utf-8"?>
<!--
This file is used by the publish/package process of your Web project. You can customize the behavior of this process
by editing this MSBuild file. In order to learn more about this please visit http://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <WebPublishMethod>FileSystem</WebPublishMethod>
    <LastUsedBuildConfiguration>Debug</LastUsedBuildConfiguration>
    <LastUsedPlatform>Any CPU</LastUsedPlatform>
    <SiteUrlToLaunchAfterPublish />
    <LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
    <ExcludeApp_Data>False</ExcludeApp_Data>
    <publishUrl>$(TF_BUILD_DROPLOCATION)\PublishDirectory</publishUrl>
    <DeleteExistingFiles>True</DeleteExistingFiles>
    <PrecompileBeforePublish>True</PrecompileBeforePublish>
    <EnableUpdateable>False</EnableUpdateable>
    <DebugSymbols>False</DebugSymbols>
    <WDPMergeOption>DonotMerge</WDPMergeOption>
  </PropertyGroup>
</Project>

 

My next step is to only have that in the drop location and not everything else.

del.icio.us Tags: TFS Tips,TFS Build

Release Build Failed in Release Management

I had recently setup a new stage in my deploy process.  It had yet to be tested and a developer checked in some code which triggered a build.  My team (devops) was promptly contacted with a generic failure message (from the person and system).  What had happened?
The build error as seen within Visual Studio was:
ERROR: The deployment for release template 'Prospect Connect' has not been completed successfully. Check the releases history for more details.
Exit: 1
This doesn’t give anyone much to go on.  Furthermore the following message was also included which didn’t help:
Exception Stack Trace:    at System.Activities.Statements.Throw.Execute(CodeActivityContext context)
   at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
   at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
Unfortunately as of 2013 Update 4 you cannot drill into the Release Manager error within Visual Studio.  My developers don’t have access to RM yet so it was up to me to see what had happened.
As it turns out the new stage I added was failing because the environment is in a different domain and it could not access the drop location.  What I wanted to change though is a way to generate good builds and green lights back to the team.  They only care about deploys to the first (dev) environment and not the next stage.
To accomplish that I removed the automation from the second stage.  I had only put it in place until the team could decide what their process was going to be.  For now I will send notification to the devops team to approve and deploy builds to the next stage.
My goal was accomplished because the system stops at that point and send back to TFS Build a successful deploy message for the first stage.
What other things in RM have you seen that return an Exit 1 back to TFS Build?

del.icio.us Tags: TFS 2013,TFS Tips,TFS Build,Release Management

Default Access in TFS Requires a TFS CAL

When adding new users to TFS be careful.  Adding them to a team sets them with the Basic (default) access level.  This means you need to be proactive when adding any users to TFS. 

Make sure you move them into the appropriate AD group within your Access levels

del.icio.us Tags: ALM,TFS Tips,TFS 2013

before you add them to a team.  Otherwise you will end up like me having to take away features from someone who was like “cool I like that feature.”  In my case they were just a stakeholder.

Ensure you do this so when true up time comes you are not paying for CALs when you didn’t really need them.

Modifying Code Reviews in TFS 2013

Recently I made a security change that effectively prevented Contributors from editing work items in the default area for the team project.  This also stopped anyone who just left the default area (the root) selected when creating a code review.

In implementing portfolio management I am now reserving the root area for epic/project work item types only.  These WIT I will end up locking down to be created/edited by our PMO office.  I do not want a random developer creating a user story with a crazy title that will be visible to senior leadership or our PMO office.

Upon searching nothing jumped out as an easy way to change the area.  Also when opening the code review work item the area path was grayed out and not alterable.  Then it dawned on me that this is a work item and like any other work item I should be able to query it and edit the results.

The query about showed me all the open code reviews that where in my root area (PD).  I then selected the results and moved them to the appropriate area path.

One final note is to remind your teams that when they create code reviews from changesets to not leave the default area selected.  Select the area that matches your product or team.

del.icio.us Tags: TFS 2013,TFS Tips

Changing a Work Item Type in Team Foundation Server is not deep

I have a whole bunch of cards I created with the wrong work item type.  I read Damian’s post on how to do this.  When I performed the steps in the TFS Web Access and in Visual Studio the existing links did not stay linked to the copy.

In Damian’s post he states that it is a deep copy of the work item (and he even has screen shots.)  So at this point I am not sure if it is because of 2013 Update 4 or if the change in the work item type is causing this. 

Below is a copy where you can see only the related link exists.

These are custom WIT but I have also tried it on Features, Stories, etc..

del.icio.us Tags: TFS 2013,TFS Tips