Terje Sandstrom

On branches and builds in Team Foundation Server

terje — Sun, 25 Oct 2009 20:49:19 GMT

On codeplex the VSTS Rangers have published the Branching Guidance II (yes, a while ago, but still very true). The basic idea there is the separation between 3 major branches, the Main (or trunk), the Development and the Release branch. One can elaborate on these and use multiple Development branches, and also a tree of release branches, but the basic principle can be summed up with these three.

Now, if we look at the different sets of build types we have, see http://geekswithblogs.net/terje/archive/2009/02/04/defining-the-build-set.aspx for details, and combine this information with the branching model above, we can see what types of builds should be set up for each branch. I’ve used the terms None, Mandatory and Optional to indicate the relationships.

Builds \ Branches	Development	Main	Release
Developer (CI build)	Mandatory	Mandatory	Mandatory
QA build	Mandatory	Mandatory	None/Optional
Deployment to Test	Optional	None	Mandatory
Deployment to Production	None	None	Mandatory

Some comments may be needed:

In any kind of branch, ALWAYS use a Check-in Build (for the Developer). It gives early warning if anything is going wrong.

Always use a QA Build (running daily/nightly at least) on your Development and Main branches, to ensure you have the right code quality, code coverage etc. I say None/Optional on the Release branch, meaning if you do a lot of code changes there, it might be wise to run it also on the release branch, otherwise there should be no need.

Decide from where you want to release to your Test Systems. You could choose any of the child branches, depending on how you want to ensure your quality. If you’re making a large development effort, you need to go through a Quality Gate before you do a Reverse Integration back to main, then you should deploy to test from your Development branch. But you always need to test before release, so a deployment to Test should be done from the release branch. A test on the development branch does only ensure the quality of the RI to main, you still need to do the Test on the release branch.

Deployment to production build should ONLY be done from the Release branch. Never ever from any of the other.

Branched history working in Visual Studio 2010 using TFS Server 2008

terje — Sat, 24 Oct 2009 20:59:05 GMT

Visual Studio 2010 (beta 2) can be connected to an existing TFS 2008 Server. Much of the new great stuff is then not available, quite naturally. But I was quite positively surprised that some stuff I had not expected to work in fact did. Which of course means it’s client stuff more than server stuff. Anyway, here comes:

History across branches: You can now see the history of a versioned item even it started it’s life in another branch, and even if you are connected to a TFS 2008 server.

You can see that this item started out in a Development (Feature) branch, changeset 33008, but in changeset 34502 it was merged into the Main.

Seminar on news in Team System 2010, September 15th in Oslo, Norway

terje — Mon, 24 Aug 2009 22:55:30 GMT

In June we ran a free 2,5 hour seminar at Microsoft on the Team System 2010. It went rather well, so it's being set up again, on September 15th. It's being done as a practical demo case, we've "invented" a problem, and uses the 2010 to solve the problem. In the process of doing that, we're going through the Architect parts, the work items, the build system, coding, branching, code reviews with the static code analysis, testing with the new Test Edition ("Camano") and more. We've done it nearly power point free :-).

The agenda, which is more like a summary of the stuff we go through during the case study, is as follows (in Norwegian) :

Introduksjon

Introduksjon til ny funksjonalitet for arkitekter, utviklere, testere og prosjektledere

Testing

No-repro bug. Automatisk lagring av testscenarier for reprodusering av feil
Testing av brukergrensesnitt - ende til ende fra test bruker med full lagring av alle hendelseer, klikk og reproduksjon i utviklingsmiljøet
Økt effektivitet og sporbarhet i testing

Source control

Sporing og visualisering av endringer i branch.
Annotated across merges
Rollback

Project control

Hierarchical work items
New work item controls
Field comparison queries
Ad-hoc Excel reports
Utvidet Project Server-integrasjon

Architect Edition

Mange nye designer-elementer for bl. Use case, component, logical class, class, sequence m. fl

Build & release

Byggkøer
Gated checking
Automatisk installering

Register here : http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032420915&EventCategory=1&culture=nb-NO&CountryCode=NO

Rune has written up more on it here: http://blogs.msdn.com/grothaug/archive/2009/08/21/under-panseret-p-visual-studio-team-system-2010.aspx

Team System 2010: Static Code Analysis, easier to set rules

terje — Sun, 12 Jul 2009 16:41:01 GMT

In Visual Studio the settings for static analysis is done on the project property page, a tab called Code Analysis. You can set which code analysis rules you want to be active. The default in Visual Studio 2008 is to use all. If you run with this default setting you will generate a lot of "noise", since there are a large set of rules. You need to create a set containing the rules you and your team find are suitable for your organization and project. This set you have to apply to every C# project in your solution. In Visual Studio 2008 there is no easy way to do this. At Osiris we made an Addin to Visual Studio to ease this. We defined the set in a separate file, and used the Addin to apply that to all projects in a solution.

With Visual Studio 2010 this will be more easy, because in 2010 you can define sets of rules. It comes with a default list of sets. You can also define your own sets, based on any of the others.

To make your own rule set, just open any of the default ones, make any changes you like to it, and save it under a suitable name. A rule set file is created, which can be checked in together with the other files of the project. This file [rule set] can now be used by any other project you have. So you only need to define it once.

You still have to select it for all the projects in the solution, but this has been made easier by having solution properties, where Code Analysis is one of these setting pages:

It's then easy to select the rule set you want for all projects within your solution.

Team System 2010 seminar - New features - and a storytelling approach

terje — Wed, 08 Jul 2009 20:06:43 GMT

We have run 10 seminars with myself, Mikael Nitell and Jakob Ehn on TFS 2008 during the last two years. These seminars were made from the point of our company's experience with the TFS system. We debated different aspects of it, and showed people how we had chosen to solve the different issues that arose. These seminars took in the range of 4 hours, and we've had around 700 people all in all participating in these seminars, with very favorable feedback.

Now in June, June 10th, we, myself and Mikael, ran a new seminar on new features in TFS 2010. For this seminar we chose a different approach from the earlier series. The earlier series consisted of quite a lot of power points, a nice series of demos, and a lot of talking. We kept the talking, but reduced the powerpoints to near nil, and increased the demos to cover mostly the whole seminar. To get this floating, we chose a kind of storytelling approach. We made up a development story, started from scratch with requirements, and worked through modeling, coding, static code analysis, bugs, testing - in fact we managed to cover a lot of the new "Camano"/Test Edition, and we even managed to show the connections between test and specifications. The approach neatly showed how good the new edition of Team System is to cover much more of the lifecycle of an application.

The feedback from the seminar was very good, which proved to us that the storytelling approach did work. So, if you weren't there, Microsoft Norway wanted to run this again, so you have a new chance the 15th of September, see the invitation here.

Mapping use cases to code

terje — Wed, 08 Jul 2009 19:30:24 GMT

There has always been a controversy between modeling and coding. All from the point where models are to be turned into code automatically, through the state where models are written and then forgotten after coding has started, to the point where one generates models from the code.

To me, code and model is representations of the same thing - the problem to be solved, or the solution to the problem. And when the solution matches the problem, which sometimes happens, all is well.

So the artifacts one make in a model IMHO it should be possible to map to code. I do believe that should be a strong guideline for which artifacts one uses in a model. If that holds, one can always reverse engineer a model from code, at least to a certain degree.

In order to make the picture more complete when one uses Use Cases for specifications is to add navigation diagrams to the suite. The term is coined by Manassis I think, and it shows how the different GUI pages are navigated. This takes form of a set of classes (one for each GUI page or independent part of a page) which depends on each other, where the dependency is named based on how you access the dependency. Ex.: “Button: Create New”. Although they say a use case diagram should be independent of the realization in form of GUI’s, I normally take a more pragmatic viewpoint, and connects these things together. One is to make a software program after all – not a theoretical thesis. I often connects a use case with a graphical page, or in some cases a page may encompass multiple use cases. Anyway, by using tracing from the use cases to the GUI pages, those relationships are taken care of, and a relationship matrix can show which use cases and which GUI’s are not connected, thus revealing missing specifications.

So, the use cases links to user interfaces (or messages for a message based system). Since the logic for the use case is not to be engraved into the user interface it has to be the Controller (or presenter or service component) that orchestrates the use case steps, hopefully most of it delegated down to the domain model. See Controller pattern within the GRASP patterns (Craig Larman).

Very often one uses the Use Case as the main work item for realizing a certain set of functionality, which encompass code on several layers, from the GUI layer, the controller layer, and on the domain layer, possibly also on the database layer. This duality, the use case both representing the code for the logic of the use case, and representing the whole work package for that behavior, is something I believe one just should accept, and not try to mitigate. It really poses no big problems, and mitigation of this would probably only cause over-complexity in the work item tracking or model.

Team System 2010 introduces the Layer Model, which can be used to enforce a more strict layering model in an application, making sure code is not placed inadvertently at the wrong layer, or crossing layer boundaries inappropriately. When one starts to take layering more seriously one also needs to be clear on which artifacts relates to which code-layer. The navigation diagram classes maps to GUI pages or GUI control classes. The Use cases maps to Controller classes. The domain model classes maps firstly to business class domain classes in code, and then, through some O/R mapping into a database model. Having a layering model, together with the necessary model elements, it should be possible to maintain a consistent relationship between model and code. One can then use whatever view one chooses and finds most convenient, and be sure that code and model is in sync. If the model then represents the specifications, the problem to be solved and the solution is also kept in sync.

Use Cases, User Stories and Scenarios - what are they - and how do they relate to TFS 2010

terje — Wed, 08 Jul 2009 12:07:09 GMT

All these three terms are used to describe the behavior of an application. They come from different process methodologies, and have different meanings, characteristics and are intended to be used differently.

Larry Guger also discuss these aspects and several others in his blog entries http://continuouslyintegrating.blogspot.com/2009/07/use-cases-and-visual-studio-2010-part-1.html and http://continuouslyintegrating.blogspot.com/2009/07/beginning-use-cases-identifying-actors.html.

The Use Case is the term used in UML and in the different Unified Process based methodologies. See http://en.wikipedia.org/wiki/Use_case for a good overall description. A use case is often looked upon as a more formal way of describing behavior, and which has to be accompanied by a detailed description following certain rules. However, a Use case can in fact be as light weight or as formal as one wants it to be. I find that this depends more on the process methodology one uses more than characteristics of the use case itself.

The User Story comes from the Scrum based processes, and is meant as a short concise way of capturing a users need for a certain behavior. See http://en.wikipedia.org/wiki/User_story for a useful description.

Scenarios comes as two different meanings, one is as a separate term used in agile modeling, see http://en.wikipedia.org/wiki/Scenario_(computing) for a description. It is very equal to a User Story, but I tend to see it as a more general term. The other meaning is as a certain path of actions for a use case. One talks of a "happy path" scenario, or an alternate scenario.

One can argue that a User Story can be converted into a Use Case, and there is a point in this. A Use Case is meant to describe an application behavior, whereas a User Story is used more freely to catch behavior "as is" from the product owner. This may lead to the case where multiple User Stories matches up to one Use Case, possibly as an Use Case with multiple scenarios, each scenario matching a User Story.

In the TFS 2010 these terms are used at different places in the suite. In the architect diagrams one can draw up a Use Case diagram, and in the Work Item store you can create User Stories. You can even create a User Story item from the Use Case artifact in the Use Case diagram. So these items can be related in TFS 2010. However, since they are not coming from the same methodologies, the mixing of these can be confusing.

I’m very pragmatic (even if I’m a theoretical guy), and I’ve noticed people have problems with these terms. I often just say that it’s more important to catch the behavior aspect of the requirements, regardless of whether you call it Use Case, User Story or Scenario. Scott Ambler has an interesting article on Agile Maturity (http://www.ibm.com/developerworks/blogs/page/ambler?entry=apmm_overview). I’ve noticed the same thing, that dependent upon the maturity of the product owners, the developers (really all involved), one uses the process differently. Also, dependent upon the size of the project, the maturity of the organization, the clarity of what is to be developed, and who’s the client and how is the contract specified, the need for formalized specifications vary based on these factors. A use case specification is more formal, than a set of user stories. Although as you so nicely shows, use stories can be converted into use cases. I fully agree. But I feel there is a one-to-many relationship between use case and user story. And then I’m not quite sure if I want that within the TFS's work item system. It just becomes too much.

I tend to take a pragmatic approach to things like this, and just say that you could argue that these terms are "equal enough" to be used interchangeably. In a real setting I would tend to try to catch as much as possible from a client (product owner) in terms of user stories, and during analysis convert these to Use Cases. After having made my set of use cases, and made sure I had captured enough to start working with code, I would convert these into work items to start the show. In order to make the terms less confusing, I would rename the User Story work item types into Use Case work item types. No other changes really required. And then I would simply use the actual User Stories as yellow notes in a customer meetings.

It is said that a Use Case need a more thorough specification, detailing the action steps it should take. One thing I’ve started to recognize is that a set of test cases is very similar to a set of use case action steps, and should never be less than these steps. So, to save on work to be done, one could simply skip the action steps, and just use the test cases with their steps as the specification. It might be that the Microsoft guys have been thinking in this route when they connected the User Story so directly with the Test Cases. It makes sense, and gives a leaner specification. But, it makes the User Story look even more like a Use Case.

Sometimes things happen, and everything stops

terje — Wed, 08 Jul 2009 12:06:32 GMT

When I started blogging I made a decision to concentrate on technical stuff. I would not write about personal things, not about what happened in my everyday life, not about my social life, not about personal trivia, but just keep it technical - write about software and software technology. And keeping my personal life and my technical life separated seemed like a good idea, and shouldn't pose any problem what so ever.

But, as everything in life, things doesn't work out quite the way one thinks. My mother got a cancer diagnostic last summer, she was operated - which went very well, or so it seemed just afterwards. At the end of last year the cancer came back, and this time the doctors could not do anything more. She was not at all prepared to die, but understood very well what was going to happen - that this was the end. She just got weaker and weaker, and on the 29th of March she died.

I hadn't expected to be so affected by my mother's death, but it surely hit me hard. I just stopped blogging, twittering, and mostly everything came to a dead stop. It has taken me a couple of months now to recover. I knew that I would react to her death, but didn't expect it that hard.

I learned quite a lot more about myself during the process, and I learned what is important and not. I stayed with my mother continusly during her last days - a week in fact, when she was almost all the time in coma, and I would never have done otherwise. It was a good way of saying farewell. Just the moment when she woke up for some seconds, looked at me and said "I'm dreaming of you" and smiled....just that was worth more than anything.

When I got back to work afterwards, which really had piled up too, most of it seemed unreal, and uninteresting. It was really hard to get anything done. Now I'm starting to get out of it, and back to normal. And summer holiday now will probably do me good too, get away from the rush of everyday life, and getting back more slowly. I plan to write up a few blog entries now during summer, about things that have been turning around in my head during the last few months. Especially the TFS 2010, and the beta which we have been playing with for some time now. We also ran a seminar on the TFS 2010 now in June, which went very well. There are a lot of new goodies coming with the TFS 2010 release - I'm really looking forward to that release.

So, to sum it all up, "Hello World ! I'm back, I think....."

Me, a Team System MVP – Wow !

terje — Sat, 04 Apr 2009 00:29:37 GMT

I was informed April 1st that I had received the MVP Award for Team System. It first appeared on the blogsite of Rune Grothaug, and later the same day a mail dropped into my Inbox from Microsoft. I knew about the nomination, but when it materialized I still got very happy and excited about it. It’s great to join such a group of talented people, but it also makes me feel the pressure to do even more for and within the community. I have always enjoyed sharing knowledge with other people, but this has normally happened in small groups. I’ve not been the typical writer or blogger, although I enjoy writing and communicating. Either I’m out of time, or I don’t feel the stuff is well enough prepared, or I’m just holding a bit back. The shy guy, you know….

The last couple of years I have been running a series of TFS seminars, which I’ve really enjoyed. I’ve also enjoyed staying on the Microsoft’s forums answering problems from other peers for some years now. This activity is mostly a spare time, or holiday activity – when I’m in projects I often run out of time to stay on the forums. And now it’s Easter, so….

I see the Team Foundation Server as a major Microsoft product, and a product which fits my interests in software development perfectly. It covers so many areas of software development, The capability of the TFS to adapt to whatever scenario you like, be it the build system, the work item system, or the data warehouse or whatever, is a tremendous advantage, and something which makes it possible for others to easily implement the system in their organization. I see it more like a framework than an out-of-the-box experience. It is THE tool to use to realize the vision of a Software Factory. I’m now really looking forward to a tighter communication with the product teams working on Team System, there is so much interesting stuff regarding Team System. The 2010 version is coming up, hopefully the betas are not far away and I just can’t wait to give my humble inputs to the process.

The MVP Award is a personal award, but for me I feel that this is also a tribute to the work we have been doing in the Project Support team at Osiris. It is this team which have realized the software factory within Osiris, and the experience from this led to the series of TFS seminars, 10 now in all – and not stopping, which started all this. The concept of “Credit where credit is due” is important to me, and Jakob Ehn and Mikael Nitell, which together with me makes up the Project Support team, should both have their share of this. Both have been creating and doing the seminars together with me. I simply couldn’t have done them without these two guys. Both are extremely competent, and I’m very happy to be working with them. They really make my days worthwhile! (Rune – need more MVP candidates? (hint, hint)). And Rune (Grothaug) of course himself also deserves credit, kicking off the nomination and working hard for us guys, and not to forget Olav Tollefsen which has been pushing me into the TFS seminars and also into all kinds of TFS related ~~problems~~ opportunities. Also thanks to Trond Brande, Microsoft Regional Director from Objectware and Mark Larezzo, Build Master from Waterfront Media for their very kind references.

Code coverage checkin policy

terje — Thu, 05 Mar 2009 03:36:04 GMT

Jakob got out a cool checkin policy after a question on the microsoft forums about this. The policy ensures that you have run a code coverage, and that the coverage percentage is above a certain set limit. See Jakob's blog for a description http://geekswithblogs.net/jakob/archive/2009/02/23/writing-a-code-coverage-checkin-policy.aspx

The code is available on codeplex, see here http://www.codeplex.com/TFSCCCheckinPolicy.