Happy New Year everyone.
We have two great sessions to start 2013.
Patterns of Testable Software – with Asaf Stone on January 24th
2013 ALM Summit in Review – with Jeremy Garner-Howe on February 7th
Looking forward to seeing you there.
So often I see developers mapping to their local folder from the middle of the source control tree to a folder on their desktop, then another folder to a different location. It gets very messy very quickly.
Some people may like to map folders this way, however I prefer a cleaner mapping implementation. When working on a team I would rather have the same folder structure as the server and everyone else on the team. Also it’s nice not to have to map each app I work on. I would rather just map once and be done with it.
Here is what I do: From a clean never been mapped TFS source control repository. If you already have mappings check everything in and remove them before doing this. (These instructions are for Team Explorer 2012)
Open the Source Control Explorer
Select the top node which should be your Server\Collection
Right click and select Advanced | Map to Local Folder from the context menu
Create a folder on the drive of your choice with the same name as the Collection. I like to create a Source folder then inside that folder create the Folder with the same name as the collection. That way if I have more than one Collection they are separate folders but all under Source.
Once you hit the Map button you will be prompted to get latest of everything in the collection.
I recommend you select No. I doubt you want everything, do you?
Now traverse the Source Control tree look and watch the Local Path at the top it changes as you move. To get a particular application just right click on the folder and select Get Latest Version and it will get it into the folder structure you see.
Have everyone on the team do this. Then when you go from machine to machine you always know where to find the source. Also it looks just like the server.
Here is a little Trick I find most people don’t know about.
When setting up a Build Definition you have to tell the build server where to get the source code from. We do this by declaring the folders to download from on the workspace tab of the build definition. It takes time to download all the files to the build server so you don’t want to get any unnecessary folders from source control.
Generally you can just select the root of the branch and pick up everything from there. Although there are times when the build you are creating does not require all the files in the branch. Lets say for example that you have two builds that run one that only builds the application and one for your WIX projects to create an install package. You likely want to keep all the files together for branching purposes. Something like this:
The folders in my example are for the following:
Builds files used by the build process specific to this application. Includes third party DLL’s we do not have the source code for.
Install WIX Project.
Resources Various resource files used by the application.
Source Application Source Code.
Now what I want is to get certain folders when building the app for a CI build and different ones when creating an install package.
I could just do this. But then I am getting more than I need in both cases.
Or to get just what I need I could do this. (Making sure I put everything into the correct folder on the build agent.
Installation Package Build:
Or I could use the cloaked status to let the build know not to get a particular folder.
Therefore on the CI Build where I want everything but the Install Folder I could do this:
And on the Install Package Build I don’t need Source or Resources so I could do this:
Batch file? Yes you heard me, batch file, you know .cmd.
This is an odd post for me, however I needed to do this recently and don’t want to forget how I did it.
When automating builds I often take advantage of invoke process. It’s a nice way to keep my build process generic and call out to a process that may change over time or is specific to branch I am building. It allows me to keep some of the process specific to the source code, by storing the batch file with the source code. This also allows me to version the batch file if it changes over time, and ensure it available to the build server without installing it on the build server. None of this has anything to do with my blog post. Whatever the reason you may be calling out to a batch file using invoke process read on.
Have you ever had trouble passing variables like DropLocation or SourcesDirectory. If they have spaces in them you will need to put them in quotes. Lets say I want to pass the DropLocation to a batch file.
The arguments property of my invoke process would look like this. """" + DropLocation + """"
Notice the double quotes around the variable, to ensure they are passed to the batch file as one argument.
“\\My File Server\Drops\BuildDefinition_1.3.4636.1”
Without the quotes in this example my batch file would have received 3 arguments
Therefore I need the Quotes.
In my batch file I want to access files in a subfolder of my DropLocation. So I need to concatenate the path passed in with another folder. Ultimately I want the location
\\My File Server\Drops\BuildDefinition_1.3.4636.1\MyFolder
The problem is with the double quote at the end of the argument this %1\MyFolder would end up being this “\\My File Server\Drops\BuildDefinition_1.3.4636.1”\MyFolder
Here is how to fix that problem.
First create a variable to hold your argument
Then when you go to use the variable use a little string manipulation. Specifically ( :~f,e ) where f = the number of characters to strip from the start of the argument and e the number of characters to strip from the end.
Therefore to get ride of the double quotes at the end of our argument just remove the last character.
Like this %DROPLOCATION:~0,-1%\MyFolder"
The above syntax will result in this “\\Server\Drops\BuildDefinition_1.3.4636.1\MyFolder” making it possible to add my folder in the batch file instead of in the build process.
I am doing part of a talk at the Microsoft Canada Office on Thursday September 13th at 6:00pm.
Here is the blurb:
Testing with Microsoft Test Manager
Coded UI tests provide a way to create fully automated tests to validate the functionality and behaviour of your application’s user interface. We’ll cover some of the ways you can use these methods of testing with TFS 2012 to increase your teams productivity. Accelerate your testing with Fast Forward for Manual Testing to quickly re-run test steps or even entire test cases in the future.
Come out it should be fun.
I did a little video for Tech Days TV demoing some of the new features of the Team Explorer.
You can check it out here.
Recently I have been on Tech Days TV and Align IT with some friends of mine.
All the shows, pertain to the next version of TFS coming out in 2012.
If you want to watch them here is the link.
If you are like me and a fan of Shelving in TFS you are going to love TFS11.
Here are some new features for Shelving that have me excited about the next release.
Instead of a copy, unshelve is now a merge. You can take those changes and Merge them in with your current local changes. Also this means that on a Gated Check in the Shelveset is merged with the main base of code prior to the private build.
In the new Team Explorer you can select work items that are In progress. So that when you check in the changes the changeset is associated to the work item.
If you Shelve this work to do something else the Work item is stored with the Shelveset. When you Unshelve to work on it you will get the work item also.
Select a shelveset while you have work in progress. Notice the Switch command below. This allows you to take your In Progress work and swap it out with a Shelevest.
I had a customer that was looking for a way to see the history of a work item in an easier to compare format then the work item itself. I searched for such a tool, didn’t find one, so I wrote this.
I uploaded it to CodePlex in case anyone would like to use it or extend it. If you just want to try it out you can download the latest version from CodePlex.
The app is pretty simple. Simply run GetHistory.exe select the server and projects you want to query and hit connect.
On the main form below, the Project drop down will be populated with the list of projects you selected from the connection screen.
Enter a Work Item ID from that project and hit enter or click Get History.
The grid will fill with each revision of the work item. If the data in a field is different than the previous revision it will be displayed in red.
Go to the Fields to Ignore tab to select work item fields you don’t care to see. Some are obviously pointless and should be turned off by default. (ie: Rev, ID, Area ID, Iteration ID, History, Work Item Type)
Connect to TFS: Use this button to switch to another server or collection or add or remove a project from the drop down.
Clear: Clears the form of the last retrieved work item data.
Export to Excel: Do I really need to tell you what this does?
I hope someone out there finds it useful.
Tomorrow Barry Gervin and I will be interviewed on AlignIT with Ruth Morton and Jonathan Rozenblit.
We will be discussing the Pros and Cons of upgrading to the next version of VS and TFS. Affectionately known as vNext or Dev11.
Feb 29th MS announced the release of Windows 8 Customer Preview and Visual Studio 11 Beta.
Looking forward to the discussions. Watch for it on AlignIT.