Upcoming Team System Events

October 24: MVP TV: Gaze into the Crystal Ball: Reporting in Team System made Easy! (Webcast)

You’ve paid your nickel and it’s time to ask the Zoltar Fortune Teller for your future: “Is my software development project going down the toilet? Will I be able to ship on time, with high quality? Can I hit my budget?” (Wait, three questions = three nickels.) Zoltar says… Let’s face it, traditional status reporting is about as accurate as I am, and worse, it takes a whole lot longer!!! Team System can help! Its built in reporting capabilities provide a strong foundation for understanding the current status of your project. Not only does it provide a series of built in reports, it gathers the metrics to allow for excellent ad-hoc reports! Using both the built in and ad hoc report capabilities, finding the current status of your project, and predicting your project’s probability of success or failure along several axis. Come learn how to predict your future! You’ll learn how to interpret the build in reports, learn what’s required to create the reports, and how to use Excel pivot tables to connect to the TFS cube for ad hoc reporting.

To register, go to: http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032391376&EventCategory=4&culture=en-US&CountryCode=US

November 5: Enterprise Build Automation w/VSTS 2008 Team System & Team Build (Portland)

Steven Borg of Northwest Cadence (Microsoft Team System MVP) will be covering some of the great new features of Team Build 2008, an inherent and powerful part of Visual Studio Team System 2008. You’ll learn to use Team Build 2008 to radically improve your code!

Come see real unit and functional tests being built, real code metrics being generated, and real work being done in an automated build. You’ll learn how to build legacy code, run tests and code metrics, rebuild your database, update your documentation, and even deploy your application into various test environments; all coordinated by a single command.

To register, go to: http://www.clicktoattend.com/?id=132684

November 15-16, 2008: Code Camp

Join Northwest Cadence and others at Code Camp where developers talk with – and learn from – fellow developers.  It is a community event and all are welcome to attend and speak.  Code Camps have been wildly successful, and we are excited to participate in this success in Seattle.  Check out https://seattle.codecamp.us for more details.

November 18: Coffee Talk – Welcome. Help Us Set the Stage! (Webcast)

We’ll briefly cover VSTS, ALM, and introduce you to the coffee talks.  Bring your questions, desires and needs.  We’ll have some fun, answer questions, and plan topics for future coffee talks.

To register, go to: http://www.clicktoattend.com/?id=132790

December 2: Coffee Talk – Visual Studio 2010 (Webcast)

You may have seen some of the fantastic new features of Visual Studio Team System 2010 (aka Rosario).  Drastically improved automated testing, architect tools that actually work, and tons of improvements to make your lives easier and time spent more productive.  We’ll cover several of the new features, and answer questions about the things you’re looking forward to.  Bring your own questions, too!

To register, go to: http://www.clicktoattend.com/?id=132791

December 4: Eagerly Awaiting VSTS 2010? (Kirkland)

Join Northwest Cadence and explore the new features of Visual Studio Team System 2010 and what it means for your business, productivity, application management, and quality. During this event, we will cover Team Foundation Server and the much-hyped hierarchical work items, new improvements to History, Merge, Work Item Queries, and the focus on Agile development.

Numerous improvements from the Architecture edition (including full support for UML 2.x) will be demonstrated, including the new Architecture Explorer which allows you to quickly and easily visualize an application from the high level down to the object dependencies. We will also highlight many Developer edition functionalities such as updated tools for performance profiling, the Historical Debugger (formerly called “Proteus”), and the ability to view affected tests based on changes to the code. Finally, we will cover the Test Edition with a focus on the “Camano” user interface, Manual Test Runner, Test Case Management, and how Team System 2010 is a strong and reliable testing platform.

To register, go to: http://www.clicktoattend.com/?id=132801

December 16: Coffee Talk – Reporting (webcast)

You may have seen some of the fantastic reports TFS provides out of the box at conferences and presentations.  We will answer lots of questions in this session: Have you wondered why the reports at your company don’t look quite as nice?  Are they missing enough data to make decisions?    What reports should you pay special attention to (Project Managers), and why should you even care about the reports (developers)?   We will also cover a few of things you need to do to really get the data into the reports and talk about how to interpret some of our favorite reports.  And, if you ask, we’ll cover how to interpret your favorites, too!

To register, go to: http://www.clicktoattend.com/?id=132792

December 30: Coffee Talk – Software Development Lifecycle

With the thousands of books and articles published on Software Development Life-Cycle (SDLC), do you ever feel overwhelmed sorting through what is hype vs. what is actually being adopted by .NET corporations?  During this Coffee Talk, we will answer this question plus others that you bring!  We will explore the complexity of software development, the current best practices for improving your Software Development Life Cycle, and industry best practices and the latest IT research.

To register, go to: http://www.clicktoattend.com/?id=132794

January 8: Eagerly Awaiting VSTS 2010? (Portland)

Join Northwest Cadence and explore the new features of Visual Studio Team System 2010 and what it means for your business, productivity, application management, and quality. During this event, we will cover Team Foundation Server and the much-hyped hierarchical work items, new improvements to History, Merge, Work Item Queries, and the focus on Agile development.

Numerous improvements from the Architecture edition (including full support for UML 2.x) will be demonstrated, including the new Architecture Explorer which allows you to quickly and easily visualize an application from the high level down to the object dependencies. We will also highlight many Developer edition functionalities such as updated tools for performance profiling, the Historical Debugger (formerly called “Proteus”), and the ability to view affected tests based on changes to the code. Finally, we will cover the Test Edition with a focus on the “Camano” user interface, Manual Test Runner, Test Case Management, and how Team System 2010 is a strong and reliable testing platform.

To register, go to: http://www.clicktoattend.com/?id=1328012

Here’s a short blurb!  For more information, or to register, send an email to info@nwcadence.com.

In this free, 3 hour Team System training session, we will explore the new features of Visual Studio Team System 2010 and what it means for your business, productivity, application management and quality. The areas we will cover are Team Foundation Server and the much hyped hierarchical work items as well as improvements to History, Merge, Work Item Queries and the focus on Agile development. The Architecture editions numerous improvements (including full support for UML 2.x) will be demonstrated as well as the new Architecture Explorer which allows you to quickly and easily visualize an application from the high level down to the object dependencies. The developer edition provides updated tools for performance profiling, the Historical Debugger (formerly called “Proteus”) and the ability to view affected tests based on changes to the code. Finally, we’ll cover the Test Edition with a focus on the “Camano” user interface, Manual Test Runner, Test Case Management and the fact that Team System 2010 is a reliable testing platform with the features you expect it to have!

Here’s a brief blurb.  To learn more, send an email to info@nwcadence.com.

The focus of this training course is on the effective use of Team System to improve an organization’s application management lifecycle. Software teams will learn not only how to use Team System effectively, but how to use Team System to improve their software development process. Developers will learn improve the quality of their code and speed development. Testers will learn to validate code quality and track test cases. Project managers will learn to use Team System to bring their projects under control. Configuration Managers will learn the best practices around branching strategies and will learn to create a tailored software configuration management strategy. As a team, you will learn how to use TFS to increase traceability, improve the quality of your code and ease the process of releasing your applications.

Branch by Quality

Figure 1 – Branch by Quality, basic pattern

This pattern is the ultimate in flexibility – but can also get very complex. It allows you to handle unique situations and respond to changes very quickly. It can be used for supporting multiple versions of an application or for more flexibility can be combined with Branch By Release to provide even more options for supporting multiple versions. Additionally you don’t have to manage quite as many branches as with other branching strategies. However, it does mean that the management of each branch may get complicated. It allows for branching for isolation, hotfixes and the easy promotion of code from dev to test to production.

The basic structure as shown here involves three branches (or code at various qualities) – Dev which is code that is in constant change and is therefore referred to as “soft” code, QAwhich is code that changes very infrequently (no active development is ever done on this branch) and is considered more firm than the code on the Dev branch and finally Prod which contains code which has been released to production (development is never done on the Prod branch). The red lines represent the branch hierarchy. In this case Prod is the parent of QAwhich is the parent of Dev. In reality the branching can be done in any way which creates a relationship between Prod and QA and QA and Dev. Using TFS you can branch QA to Prod and QA to Dev or Prod to QA to Dev or Dev to QA to Prod to create this relationship. The only thing this effects is the default selection of drop down boxes in the merge wizard.

The reason why we refer to this pattern as Branch By Quality is because of the quality of each branch. Dev is potentially testable, QA is potentially releasable and Prod is released code. Each branch must maintaint this quality. Another hallmark of this pattern is a single path to production. Branch by Release has multiple paths to production – each new branch is a new path to production. With this pattern, builds for production ALWAYS come out of the QA branch (not the Prod branch as you may have assumed).

The process for releasing code is to promote it from Dev to QA, build the QA branch and test the compiled assemblies. If all tests pass, you do NOT rebuild the code – you simply deploy the already compiled assemblies. Then you promote the code from QA to Prod as a safekeeping. Note also the pairs of green lines which represent merges. As before, always Merge down, Copy Up to promote the smoothest transition possible.

Dealing with Bugs

Let’s look at a simple example where code has been promoted from Dev to QA (so the users can perform User Acceptance Tests (UAT)) and development on the next release has begun on the Dev branch. In this situation, assume a bug has been found by users during the UAT and needs to be fixed. Figure 2 shows this scenario.

Figure 2 – Bug in Test

Unlike Branch by Release, you cannot just make a fix on the testing branch because code on that branch is always potentially releasable which means that making changes to that branch can potentially cause problems. To avoid this you take a branch for isolation – in this case it follows almost the same pattern as performing hotfixes (discussed next) – from the QA branch. You can’t branch from Dev because if you do there is no direct way to merge from the isolation branch to the QA branch (you can do a baseless merge but in this case it causes more problems than it solves). So, take a branch from QA (at the point you promoted the code from Dev to QA and labeled the code on the QA branch) and fix the code on this branch. Perform testing on this branch and when it is ready for UAT, promote it to the QA branch. When UAT is complete and the fix verified, merge the QA branch down to the Dev branch. This ensures that the fix makes it back into the next version of the code.

This is a fairly simple example but they will get more complicated as I add to this strategy. I will do this in a new post in the near future.

Branch By Release 

In the first on a series of posts regarding branching strategies, I’m going to start off with the ’super’ pattern (why I call it a ’super’ pattern is discussed at the end of the post) – Branch By Release. What does the Branch by Release pattern look like and why use it? The figure below shows the pattern and maps out the usage for it (double-click the image to enlarge it).

Figure 1 – Branch by Release, basic pattern

This pattern is most useful when you are supporting a single version of an application (say a website for example). It can also be used for multiple version support but that can get fairly complicated when you get into branching for isolation, and long running features that may take several versions to implement.

The basic structure as shown in the figure is to build and when you are ready for test, create a new active branch for development and release the code on the “parent” branch (I put parent in quotes because even though it is the parent, branch relationships are generally bi-directional and so this designation is for a frame of reference only). While code is in production you can make fixes to it even while the next version is under development. When the fix has been implemented, simply merge down from production to the active branch.

This is perhaps the simplest of all branching and merge patterns. The reason why this is frequently unsuitable for complex branching and merging, as noted above, are when frequent, temporary branches or long term branches are needed that may span releases. While you can use this pattern for those types of requirements, by itself, it does not offer support for complex scenarios without a lot of extra work.

Dealing with Bugs 

Now that you’ve seen the basics, how do you deal with bugs? There are two scenarios for fixing bugs – when one occurs in code under test and when one occurs in code in production. These two scenarios are represented in Figures 2 and 3 respectively.

Figure 2  - Bug in Test                        Figure 3 – Bug in Prod

A bug that is found in Test is the simplest example because you can simply make the fix in test and merge it down to the active branch for the next release and then the fix is in both versions.

A bug found in Production is a little bit more involved – but not much more. If at all possible, see if the users can wait until the next release is out – that way you don’t have to mess with Production and you can follow the pattern for fixing the bug in test. If the users absolutely need it now (or the code under test is due to be released too far in the future) you can fix and test the bug using the code in production and merge the changes down to the code that is under test and then to the active dev branch.

The next question to be addressed is what to do with the test environments. If you have the luxury of multiple test environments, you can simply test the production changes in a separate test environment. If you only have one test environment, you must stop the current round of tests (for Release 2 in Figure 3 above), release the code fixes for production into test and then release to production. At that point you need to merge the changes from production (Rel 1) down into Release 2. Then re-release the code from the Release 2 branch into the Test environment. Once those tests have passed, merge the changes from the Release 2 branch down to the active development branch for the next release.

Common Code 

 The last item to consider is common code. There are two options for dealing with common code. The first is to have the common code on its’ own branch and to simply reference the project containing the common code (i.e. never deal with the branch directly, just code on your local machine that you retrieved from this branch). This presents LOTS of problems. The biggest is that the common code can change from under you – maybe even daily. And if you manage to overcome this problem you have to deal with synchronizing releases which can also be problematic. So you might be thinking, “Jeff, why don’t I just reference the dll’s from the most current release of the common code?” Well, you can do that under a certain circumstance. That is – the dll’s must also be in version control (i.e. please don’t reference the common code by using a dll found on a server share somewhere – you are just asking for pain when that dll gets “suddenly” updated out from under you). The other issue is that you cannot really update the common code, if needed, without seriously ticking off the people who own that code – maybe they’re more friendly in your organization when you introduce code changes that they weren’t aware of…

But what if you are going to need the latest release of the common code and YOU want to choose when to get a new version? That leads to the second option – branch the common code into your active dev branch (Figure 4).

Figure 4 – Common Code

This allows you to do two things: 1) You can actually change the common code without screwing up the common code project (don’t do this unless you plan out with the common code owners how to version this and get your changes back into the main common code branch) and 2) You can perform updates on the branched common code (i.e. merge down from the common code dev branch (or, preferrably the QA branch) to your active dev branch) when you feel like the common code is stable enough for you to use. This elimintes the problem of the code changing out from under you. There is one drawback to this approach – once you do the first branch from the common code to your branch and then you branch from say Release 1 to Release 2 there is no longer a relationship between your branch of the common code and the main branch. In TFS you can solve this problem by performing a baseless merge between your new branch of common code and the main branch of common code which will create a relationship between the branches.

Pros and Cons

So when should you use this pattern and when should you avoid it? 

Pros 

• This is the simplest model to use
• It’s a great choice for single release web applications
• You use the same structure for hot fixes and maintenance releases
• There is a minimal amount of branching

Cons

• Not as flexible as other patterns
• More difficult to manage multiple releases (more merges are required depending on how many versions you support and they get more difficult as you move along)
• Because file history needs to be traced back to the previous branch, it takes more work to trace

Final Thoughts

At the beginning of this post I mentioned that I classified this as a super pattern. There are many several other major patterns available – branch by quality (Prod/QA/Dev), feature branches, and release by manifest. The reason why this particular pattern gets the designation of a super pattern is because it can be the top level when used in combination with other branching patterns (yes, you can combine patterns which will be discussed in a later post – but it can get very, very complicated). So, for example, you may use this branch by release strategy and for each release you may have a series of features that are broken up into their own branches. You may decide for each feature to have a Dev and QA branch (the ‘Prod’ branch in this case would be the main branch for the entire release). However, I can’t think of a good situation in which you would ever use this as a sub-pattern for one of the other major patterns.