Jose's Blog : SCM

Creating a Customized Guidance Repository

josealmeida — Fri, 19 Sep 2008 04:55:00 GMT

As a consultant part of my job is to provide guidance to our customers on the best way to use our technology, namely in terms of application development practices. Over time, you start to better understand the type of customer you’re working with, what works, what doesn’t and you start to optimize your own delivery processes. You reuse material and refine it the next time around. That’s the nature of our work in the Services organization.

Lately I’ve been involved in several engagements in the Application Platform Optimization space, mainly the Application Lifecycle Management suite of Offerings.

At the present I’m working with one customer who has gone through the Assessment phase and we’ve arrived at a six phases maturity growth roadmap that they’re starting to implement. One of the key aspects of this type of custom engagement is that all the experience gained by the customer and all the guidance delivered by the consulting team, should be persisted by the customer. We’re working with a small team within the customer and they are the ones who will have the responsibility of creating their own guidance and internal best practices and sharing all this information with the rest of the organization. So to collect, persist, distribute and, later on, update their in-house customized guidance for application architecture, development and lifecycle management, we’ve chosen to use the Guidance Explorer tool available on Codeplex.

The use of this tool turned out to be a great fit for this scenario. Instead of compiling one giant document, that would go through several versions and would quickly fall out of synch, the customer is now publishing and updating guidance, based on an existing database of industry and technology best practices. Guidance articles have their own metadata, the lifecycle of each piece of guidance is independent of each other and, if needed, all the guidance can be compiled into a Word document for a hardcopy reference. Additionally, one of my favorite features is the ability to subscribe to the guidance through a published RSS feed and receive a notification whenever guidance changes or a new best practice is published.

Synching TFS with other Source Control systems

josealmeida — Wed, 17 Sep 2008 15:33:42 GMT

Many of us in the field have come across heterogeneous source control environments within the same organization. Some organizations, having multiple source control systems, wish to have some way of synchronizing TFS with their other systems. I've seen this when development teams who are used to the Microsoft development tools tend to prefer Team Foundation Sever and sometimes operations teams, who are responsible for deploying and maintaining the software produced internally maintain a portfolio of versions of the software in other control systems, like ClearCase for instance.

The TFS Migration and Synchronization Toolkit allows developers to build custom tools that provide migration and synchronization capabilities with other version control systems.

There's a new version of this toolkit available in Codeplex. This release includes enhanced support for the migration of branches and merges.

Branching Strategies

josealmeida — Thu, 10 Jan 2008 21:48:00 GMT

Under Software Configuration Management, branching and merging are common features that help maintain stable code bases and scale the development effort by synchronizing parallel development. However, depending on the size of your product, the size of your team, your isolation requirements and your development cycle, parallel development can become quite overwhelming, so it's very important to define a good strategy for branching and merging that meets your needs. This isn't always straightforward, so here are a couple of guidelines I usually use to tackle this issue.

The first thing I try to find out are the isolation requirements for parallel development, how many development teams there are and what are the stabilization protocols (how many quality gates there are and how many different test environments there are where these gates are checked).

Having this information helps me to define the logical structure for the branching strategy as well as the physical source control structure to support it.

One thing I always have to look out for, is to make sure that the logical structure is applicable to the physical structure. For this I usually define a set of use cases that act as a model that I "run" on both the physical and logical structures to check if they are supported.

Here are a couple of scenarios I usually contemplate:

Fixes
Release Stabilization
Code Promotion

I try to check all of these scenarios, considering that a mix (or all) of them might occur simultaneously. Here's a possible scenario I try to work out:

"Imagine there's a team working on a new release of feature A, part of another team is working on a fix of a previously released version of their feature (feature B) while the rest of the team is working on the next version. In the meanwhile, a third team is required to release feature C to a new test environment for functional testing by end-users."

Some questions that I might ask for this scenario:

How many teams/features are there?
What should the physical structure of my source control repository be?
How many independent branches do I need to make this scenario valid?

The Branching Guidance by the P&P team is an excellent place for different approaches to these questions and many more.

So, what do I really look out for when defining a branching strategy?

Good Logical Structure
Good Physical Structure
Make sure the logical structure is applicable to the physical structure
Run a model on both the logical and physical structures.