Here’s the nutshell details:

IMPORTANT REGISTRATION INFORMATION:

Registration opens on January 14th, 2014 at 9AM Pacific at https://www.buildwindows.com. Don’t be late – Last year’s conference was booked in less than an hour!

You can follow the //BUILD Twitter as well at https://twitter.com/bldwin

Excelsior!

Obviously that sort of feedback made it to the MSDN technical writers backlog because they recently published an article that explains a lot of this. It called Work with team project artifacts, choose a process template. It provides a good breakdown of what Work Items are part of each template and how they relate to one another. Not just for the Agile and CMMI process templates but for the Scrum template as well.

But don’t stop reading the article there. If you look at the index for the article, there’s a pretty thorough breakdown of each template, what reports are available in each template, and more. A lot of customers I work with often tell me “We’re a Srcum-but shop” or “We’re a Wagile shop,” and how can we customize TFS to fit our process?

By looking through this article, understanding what work items, reports, and other artifacts that are in each process templates, you can get a better of which process template you’d like to start with as your base process template and start customizing from there.

I highly recommend you check out this article if you’ve ever been curious about what makes up a given process template and wanted to see which one would be the right one to start with.

Excelsior!

IMO, TechEd is the Microsoft conference you attend if you want learn all about what’s current at Microsoft, best practices on solution building, and glimpses into products that are about to ship. Attendees range from IT Professionals to Developers.

//BUILD is more for the people who like code. Not just .NET code, but people who want to learn about developing on the Windows platform who are familiar with other development platforms as well.

TechEd 2013 North America is going to take place June 3-6 in New Orleans, LA. If you can’t attend, you can attend virtually by watching via Channel 9. To build your schedule of what you might be interested in viewing, check out the TechEd Channel 9 page for topics and schedules.

//BUILD 2013 is going take place June 26-28 in San Francisco, CA. The schedule is still being flushed out so they haven’t announced their Channel 9 feed yet, so keep watching for announcements through their web site.

Share and enjoy!

Excelsior!

Personally, I had been curious what the user experience would be like if the check-in took longer than expected. Well, while working on a project for my team and checking my part of the code into TFS, the checked took longer than expected and I received the following error message:

You might be thinking “big deal”. This isn’t all that exciting. But in a past life, I’ve been bitten by networks hanging for whatever reason during a code check-in and I never quite knew exactly what changes made it into the repository and which ones didn’t. So I ended up doing the check-in again and got prompted that  a number of files are the same and it was the last two files that hadn’t made it so those where checked in finally.

By receiving the error message above, I knew immediately that all the files I was trying to check-in weren’t committed to the repository, so all I had to do was click the Check-In button again. Obviously my network connection the server was better the second time around and the code made it in as expected and a new Changeset was created.

We’ll now return you to your regularly scheduled worked which was previously in progress.

Share and enjoy!

Excelsior!

It’s a pretty large download and Brian offers a good technique for you to use to do an unattended download.

Share and enjoy!

Excelsior!

As part of the development process, developers can either been given tasks through a system like Team Foundation Server (TFS), a project plan, or some other means like email. The important thing to think about is tracking the developer’s work back to the changes in code.

When I was wrote code full time, I often would try to resolve as many tasks as I could if the code changes were related to the same modules(s). Sometimes this was effective con clearing out a bunch of work off my plate, but when it came to integration time with the rest of my team, we could end up with a lot of changes we would have to reconcile and integrate.

Regardless of the development process you adhere to, it’s really a good idea to encourage developers to work at one task at time, only change the code related to the one task, and integrate often. This makes finding out where incorrect code changes are made and corrective actions can be done quickly. Even using continuous integration techniques isn't going to help figure out what changes broke if you try to change too many requirements at one time.

With Team Foundation Server (TFS), we don't force you to work in any particular manner; however, it is encourage that you work on one task at a time for better traceability. Assuming you use TFS for work management as well as SCCM, upon code check in, you can enforce (or encourage) that all code that is checked in be associated with a work item. A work item can be defined to be anything you'd like it to be: bug, developer task, test case, user story, requirement, and so on.

The Changeset

When you check in code into TFS, a changeset is created. A changeset is a set of files and work items associated together a time of check in. If you don't associate work items with the code, the changeset will just consist of just the set of files. The heart of this is due to the fact that the check-in process is an atomic transaction. When you perform a check in, the process tells TFS how many files and work items are going to be checked in. Assuming all the files get transferred properly into TFS, TFS will generate a changeset number. This number can be used to trace back what code files and work items were worked on.

In the following screen shot, Changeset 89 is made up of 1 code file and 1 work items. Obviously this is pretty simplified, because all the code changes made were in one file related to one task. Even if it wasn’t and you had multiple changed files to one task, you can see that all the code changes that were related to the one task.

Code Annotation

A lot of development groups try to encourage their developers to document every change that is made in code. Sounds good in principle but difficult to implement in practice. Why? Because you might end up with more comments than code, or you might end up with a situation where you have comments inside logic blocks just to show where code changes were.Your modules might start looking like this:

Me.GetPeopleButton.Font = New System.Drawing.Font("Microsoft Sans Serif", 8.25!, System.Drawing.FontStyle.Regular, System.Drawing.GraphicsUnit.Point, CType(0, Byte))
Me.GetPeopleButton.ForeColor = System.Drawing.SystemColors.ControlText
' 2012-12-03 NI - Task 24 – Block Start
Me.GetPeopleButton.Location = New System.Drawing.Point(6, 376)
' 2013-02-04 AJ - Task 42
Me.GetPeopleButton.Margin = New System.Windows.Forms.Padding(4, 3, 4, 3)
Me.GetPeopleButton.Name = "GetPeopleButton"
' 2013-02-16 KB - Task 47
Me.GetPeopleButton.Size = New System.Drawing.Size(124, 23)
' Task 24 – Block End
Me.GetPeopleButton.TabIndex = 0

You certain don’t want to discourage your developers from putting in comments, but there is another way to look at what lines of code were changed, by whom, when, and why. This is the Annotate feature. To access this feature, its found in the content menu in the Source Code Explorer when you're looking at a file's history list.

When you view the Annotation of the file, in the left hand margin, you will see the changeset number, the name of the person who made the modification, and the time of the change. The changeset number is a hyperlink so if you click on it, you will be able to see what file(s) and work items are associated with the changeset. This can be really useful if trying to figure out who made a particular code change -- because you'll see who made the code changes -- and why -- assuming the changeset has a work item associated with it. You still want to encourage your developers to add comments to their code, but if they forget.

Excelsior!

Brian Keller has published a Team Foundation Server 2012 and Project Server 2013 Virtual Machine with Hands-On Labs and Demo Scripts. This is great because it comes with a couple of projects already set up in Project Server and you can see how data can flow between TFS and Project Server (or from a project manager’s point-of-view, see how data can flow from Project Server to TFS).

It’s a pretty large download and Brian offers a good technique for you to use to do an unattended download.

Share and enjoy!

Excelsior!

In order to use Hyper-V on windows 8, you need a 64- bit system that has Second Level Address Translation (SLAT). SLAT is a feature present on many of the current generation of 64-bit processors by Intel and AMD. To determine if your processor supports SLAT, you should download the Windows Sysinternals tool called CoreInfo. Once you download and extract the EXE from the ZIP file, you’ll need to run it from a Command Prompt that was select to Run As Administrator. If you’re running Windows 8, the easiest way to do that is by searching the form the Command Prompt using Search, right mouse click on the program and click on Run As Administrator from the application specific menu along the bottom of the screen. You’re not just going to execute the CoreInfo.exe, you’ll need to use the –v switch as seen in the screenshot. If you’re process supports SLAT, you will see a “-“ (minus sign) next to the EPT field. This confused me at first because I would have thought the “*” (asterisk) would have meant the feature was enabled. When I got my most recent computer, the specs said it supported SLAT and it does, but when it shipped, that feature was disabled in the BIOS, so if you think your system supports SLAT and EPT is showing an asterisk, you should check your BIOS.

You’ll also need to use the 64-bit version of Windows 8 and a lot of memory. If you’re machine only has 4 GB of RAM, you meet the minimum requirements, but it’s not going to be really useful. You should have at least 8 GB of RAM because you have to share the RAM with the VMs you’re running.

One of the problems I always had with running VMs on a laptop is connecting them to the machine’s WiFi. One option was to use Internet Connection Sharing as outlined in Ben Armstrong’s blog or you can use Remote Access Service (RRAS) as outlined in John Paul Cook’s blog. Both work but both have their disadvantages. By using Windows 8, you’ll be happy to know that Hyper-V supports WiFI out-of-the-box. Huzzah! So setting up your VMs to your WiFi is as easy as going to your Virtual Switch Manager and creating a switch that uses the WiFi NIC rather than the wired NIC.

On the Windows 8 Blog, there’s really good article about the decision bringing Hyper-V to Windows 8. Definitely a good read but even better is the following video that provides a quick walk-through of how Hyper-V works in Windows 8 from the article. 

Download this video to view it in your favorite media player:
High quality MP4 | Lower quality MP4

Share and enjoy!

Excelsior!

One of the coolest features we introduced in the TFS 2010 is the Branching Visualization feature. This feature allows you to see if a changeset in one branch has been added another branch or not. This is done by viewing the changeset history you’re looking at and selecting Track Changeset either from the context menu or from the toolbar.

You’ll be promoted by a dialog box to select which branches you want track the changeset through. In this example, we’ve made changes in the Dev branch and we’re going to check to see if it’s been promoted to the Main and Release branch.

Once you press the Visualize button, you will see if changeset has been promoted (or demoted) to the branch you’re looking for. The default view is hierarchy (Screenshot below on the left). This is a good way of viewing the branches it provides you with a glimpse of your branching strategy as well. In this example, the “Main” branch is where we started the project and we created two branches from it: Dev and Release1. All development is going to be put in the Dev branch, promoted to Main and then promoted to a release, in this case, Release1. An alternative way of viewing the branches is by viewing them by timeline (Screenshot below on the right).

Regardless of the view, in the screenshots, you can see that we haven’t promoted Changeset 26 to Main or Release1. To find out more about Changeset 26, double click on the changeset and you’ll see the changeset details in the Team Explorer Window. In this example, we have two Work Items associated with the changeset. One is a task and other is a code review. If you’re the person responsible to promote code from one branch to another, you might want to recommend taking advantage the Code Review feature we introduced in TFS 2012.You can then have an SOP (standard operating procedure) that only changesets with code reviews performed on them can be promoted.

To promote Changeset 26 to the Main branch, you simply click and drag the changeset from the source branch to the target branch. This will trigger the merge process against the new branch.

So what happens to the changeset you just merged? The merge will be added to the branch’s project on your local workspace. From there, you should follow your standard quality gates for ensuring that the code works in the branch, check it into TFS, and proceed with the next changeset to promote.

To learn more about branching and merging strategies, you should take a look at the Branching and Merging Guidance document our ALM Ranger Team put together.

Excelsior!

When I was previously responsible for Quality Assurance and Operations Developers, I become really focused on ensuring our team was building healthy systems, not just quality systems. What's the difference between a healthy system versus a quality system? One might think they are one and the same, but in my opinion, they are very different. Let me try bring this down to a personal level while I relate this to a system development level.

A couple of years ago, I started playing basketball again with a recreation league. I used the gym on an irregular basis, rode my bike every other week for about 10-20 miles, and so on, so I felt I was in okay shape. Before I undertook the journey of playing on the court in a game, I went to the doctor to get a physical to make sure I wasn't due to for a heart attack or something worse if I started playing again. The doctor ran a series of tests on me and in a couple of weeks, he gave me the “all clear” sign. So when it came to game time, I felt I was in good shape to play "big boy basketball." Turns out, after a couple of fast breaks, transition defense sprints, and fighting for position for rebounds, I was pretty winded and felt like passing out.

Now let's take this story and apply it to system development. Going to the gym, riding a bike, etc. could be equated to activities that an individual developer does. They write code, they compile it, and maybe do some light testing. Going to the doctor for physical is like taking your application and giving it quality assurance (QA) to test. Often times, QA only focuses on the tests they are aware of for a given release, maybe some basic regression tests, and make sure things are working as designed and within established parameters, thus ensuring that what the developers have built is a "quality system." Once the application has been deployed to production (aka big boy basketball), you get to see how well the quality system scales. The application performed well under the standard battery of tests (much like the human body does during controlled conditions), but when accessed by hundreds and thousands users, the system could start locking up, performance becomes extremely bad, and so on. What we find is that this quality system isn't a very "healthy system."

How can you check to see if your application is a healthy system? This can be done by taking testing to the next level, which is executing load and performance testing against it. I've seen too many companies wait until the final stages of deployment to determine if their system can scale to level they've promised to their customers.

Some companies wait until the end to do this sort of stress testing because the cost of setting up test rigs can be expensive because they have to pay for virtual user licenses. Using Visual Studio Ultimate, in addition to all the developer benefits the IDE brings, it comes with the features to do Web Load and Performance testing for up to 250 virtual users on the local workstation, but it can also be configured with full test rigs with an unlimited number of virtual users. You’re only real limit is the number of virtual users your rigs can scale to.

If you think back to the basketball example, instead of waiting until game day to see if your application can scale, using load and performance testing during practice (integrated development) and scrimmages (QA), you can become real confident that the system you and your team is developing is not only going to be a quality system but a healthy one, too. If you haven’t looked at Visual Studio Ultimate lately, I recommend you do. To see how you use Visual Studio for Load and Performance testing, check out the Introduction to Web Performance and Load Testing with Visual Studio Ultimate 2012 Hands-On Lab documentation.

Excelsior!