Monday, April 20, 2015

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: ,

Monday, April 13, 2015

Release Build Failed in Release Management

vswhitelogoI 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?

Tuesday, March 31, 2015

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: ,,
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.

DefaultLevel

Monday, March 2, 2015

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.

image

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: ,

Thursday, February 26, 2015

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. 

image

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

image

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

del.icio.us Tags: ,

Thursday, January 29, 2015

TFS Wildcards in Workspaces Command

A user wanted to know how to list all of a certain users workspaces across all machines without having to install TFS Sidekicks.  It is a simple command and you can use the * wildcard for the owner or computer.
tf workspaces /owner:UserName /computer:* /collection:TFSURLIncludingCollection
This will produce a nicely formatted list of workspaces for that user.  This could be used in a script to delete workspaces for a user but with Sidekicks around that is my preferred option as an administrator.
del.icio.us Tags: ,

Tuesday, January 27, 2015

TFS Wildcards and History

A coworker had asked me the other day if it was possible to get a list of changes for a subfolder with a certain name.  This subfolder lets call it Views is located in multiple places on the branch.
I tested out to see if you could place wildcards in the itemspec path.  The answer is no you cannot.  You can only place wildcards at the end.  For example this does not work:
tf history -server:http://tfs/tfs/MyCollection $/MyProject/Branches/Database/MSSQL/*/Views/* -recursive -format:detailed –noprompt
This does work:
tf history -server:http://tfs/tfs/MyCollection $/MyProject/Branches/Database/MSSQL/* -recursive -format:detailed –noprompt
In the end you would have to write a script to sort through the files in each changeset and filter out just the changesets returned that had /View/ in the path.  If I get some time to write this script I will post it.  Hope this help you.

del.icio.us Tags: ,

Tuesday, January 13, 2015

Using TFS 2013 Update 4 License Change for Agile Teams

We are in the process of upgrading to Update 4 and were figuring out how the license changes affect us (was hoping for costs savings.)  They don’t and probably won’t save us on MSDN costs.  Read on to see how it could save you.

Development

All of our developers and testers have an MSDN Premium or Ultimate.  This covers them not only for TFS but also access to all there test environments and whatever software they have installed.  They will remain at the Advanced access level.

Product Management

The next layer of user is the product owner.  Our product owner sits with each team and helps to manage and groom the backlog.  They also validate work is done which means they use development environments.  That being said they will continue to need MSDN Premium.
I was hoping we could drop them down to Basic (TFS CAL) but the environment thing stops that.  With Basic access a product owner could plan and prioritize user stories for their team but not features.  I guess features is what Microsoft deems advanced planning.  This would be a big cost savings to some companies.
Our next layer is product manages themselves.  While they don’t hop on the development environments that still need to be able to plan and prioritize at the feature level.  With Microsoft’s new license structure nothing changes for us.  Again to get just that feature requires an MSDN license.  That is pretty costly unless I can get them to use the feedback or storyboarding features.

The Stakeholder

This access level is free and allows the editing and creating of work items.  If your product managers are willing to do some work in Excel this will provide your company with some cost savings. 
They can prioritize by using the Team add on in Excel.  To do that just have a query of the features and make sure the Stack Rank is one of the columns.  They can then modify the stack ranks to prioritize the work items.  Once that is done a publish up to TFS will update it for the teams to work from.
This could become cumbersome as working with the stack ranks is not easy for a large number of work items.  The PM’s at my company need to be able to work fast so this will not fly.  Hopefully some one else out there will be able to do this and same some $$. 
Happy ALM’ing!
del.icio.us Tags: ,,