Ask what Team System can do for you

7 בנובמבר 2007

תגיות:
תגובה אחת

As part of my job as a consultant at SRL, I get to visit many companies and see different implementations of Team System. Some companies thought that Team System is just as a fancy replacement for VSS and without any preplanning they installed TFS and started working with it. Shortly after they started noticing they actually had to work harder to keep the system updated. I always tell them my motto for every supporting system in general and especially regarding Team System:


Ask not what you can do for Team System – Ask what Team System can do for you !


Bellow is the list of the top 5 most common misperceptions regarding source management in Team System you should be aware of (and hopefully avoid):


1. Team Project – "Do we need a team project for each project we create ?"



The name "Team Project" is built from two words, "team" and "project". For some reason, people tend to read only the second part and totally miss the "team" purpose of this object. Team Project are often used as a container for solutions and projects in the same team, I've even seen team projects being used for branching monthly versions of the same product.


Team Project is meant to be used for a team that works for a shared goal. Your teams can have different managers, sit in different buildings, work on different products and even develop using different languages. as long as your teams have a seared goal (such as an application on a major version) they should use a single Team Project.


2. Workspaces – "Why bother with many workspaces? one is enough !"



One of the most common mistakes I see is the misusage of workspaces. Programmers often think that workspace is just a fancy name for the VSS equivalent of "working directory". By think that, programmers usually create a single workspace and map it to the tree's root folder. By doing so, they can't use all the advantages that workspace allow. advantages such as isolating your development on different products or switching between different versions of the same product and many more.


Workspaces are great for keeping your work isolated, you should create and work on different workspaces for each product\version.


3. Changeset – "Was the bug fixed on changeset 32453 or 32468?"



As I mentioned in the previous paragraph, some people think that Team System is just VSS with new icons. they may use all Team System as to offer (such as work items, builds etc`), but they don't create any linkage between the different data items. must commonly is not to link changesets to the relevant work items and use only comments (and labels) to manage their code.


Changesets are a powerful objects that make a major change in the way changes are stored in the source control and way you should manage changes in your code. Changesets are used to wrap all the files (and folders) that were checked-in to the server. This ability on its own is enough, but when linking the changeset to the work item that initiated the changes in your code, you create a real-time documentation for the reasons of the code changes for each row of code in your file.


4. Work Items – "Just fill the title and write the other info in the description"



A programmer once told me that he think Work Items are BAD, he doesn't understand what he need to do and often have to call the initiator of the work item for clarifications. Well, in some aspect he is right. don't get me wrong, I think work items are very important objects, but when companies don't customize the structure or over-customize (by required many fields) they create the opposite action.


When customizing your work items, you should avoid making the process too long or too descriptive, keep all the fields understandable and don't create a cumbersome process that will create overhand and make the participants unwilling to provide important information.


5. Branch – "We don't need branching, we are a small development group"



The sentence above I normally hear for small development groups. they tend to think that if they are only 5-8 programmers than they don't need any versioning or branching. In many cases if they do use branching it is used as just a backup folder and not as part of the application lifecycle.

Branching is meant to "freeze" the state of your code to and allow your team to work on different version of the same application (for example production version, QA version and development version).
Branching is very impotent no meter the size or of your development team or the fact that you may sit next to one another. Branching should be part of your development lifecycle and should be planed during the planning stage.

In summary, Team System has many features and tools to assists your development efforts. When implementing any system you should always plan your steps and be familiarize with advantages the new system has to offer.


Good Luck!

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

תגובה אחת

  1. Ariel Ben Horesh28 בנובמבר 2007 ב 14:17

    Another common mistake.
    People think they need a Team Project for every VS project they have.
    and that is just awful!

    הגב