W repozytorium przechowywana jest "ostateczna wersja" pliku. Cofanie się do "starszej" wersji pliku jest możliwe, dzięki przechowaniu tzw. odwrotnych delt. Najpierw wgrywany jest nowy plik (obok starego), a potem asynchronicznie liczona jest wartość takiej delty i ona jest aktualizowana w repozytorium (zastępując "starszą" wersję pliku). Takie "cofanie" się jest kosztowne z punktu widzenia wydajności, dlatego TSF w warstwie aplikacyjnej przechowuje niezależny bufor zawierający ostatnio używane pliki.

Dodatkowym udogodnieniem TSF jest Team Server Foundation Proxy. Mechanizm ten utrzymuje bufor plików, a równocześnie spełnia rolę zarządzającą, w wyniku czego operacje typu "pobierz najnowsze" są wykonywane lokalnie, a zmiany są niezależnie synchronizowane do repozytorium dostępnego dla wszystkich uczestników projektu.

Pojemne SDK

Team Server Foundation dostępny jest w wersji 1.0, a mimo to Microsoft opublikował już dosyć przyzwoicie opisane API i pakiet SDK, pozwalający dostosowywać działanie zarówno Team System (w sensie klienckim), jak i TSF. Ponieważ tak naprawdę w wielu miejscach od czasu premiery Visual Studio .Net 2005 działały wersje beta czy RC TSF, potrzeb w tej dziedzinie powstało całkiem sporo.

Team Server Foundation składa się z wielu serwerów i Microsoft przygotował dedykowane narzędzie - TSF Administration Tool, które pozwala na wspólne zarządzanie uprawnieniami dla tych platform. Dodawanie nowych użytkowników nadal wymaga jednak oddzielnych modyfikacji zapisów w Active Directory, TSF, Sharepoint i Reporting

Services. W przyszłości zapewne zostanie to poprawione, ale trzeba mieć świadomość, że już dziś można użyć TSF Administration Tool do tego, by np. przydzielić dostęp nie tyle do TSF, ile do określonego raportu.

Projektowanie własnego zadania (workitem) może być uproszczone dzięki wykorzystaniu koncepcji Domain Specific Language. Do Visual Studio .Net 2005 dostępny jest pakiet DSL Tools. Na portalu GotDotNet powstał projekt, który używa właśnie tego pakietu i pozwala na graficzne projektowanie typów zadań.

Można także włączyć mechanizm, który po wysłaniu kodu do repozytorium automatycznie uruchamia build (tzw. ciągła integracja). Istnieje także dodatek do CruiseControl.Net, ale Microsoft opracował własny motor, który można pobrać z witryny MSDN. Dostępne są też narzędzia do zarządzania TSF z poziomu linii poleceń, provider MSSCCI do Visual Studio 6.0/2003, integracja z Eclipse i wiele, wiele innych. Spośród innych ciekawostek warto wymienić Teamlook - narzędzie, które pozwala na pracę z TSF z poziomu Outlooka. To tak naprawdę folder poczty zawierający listę zadań przypisanych do użytkownika.

W Polsce powstał system o nazwie S˘P, który wykorzystując funkcjonalność serwera Team System pozwala na gromadzenie komentarzy dotyczących systemu informatycznego. Mogą to być np. sugestie zmian, błędy wprowadzane na specjalnym portalu itp. Specjalny dodatek dla Outlook pozwala łatwo obsługiwać część zgłoszeń niezwiązanych bezpośrednio z "deweloperką". Za jego pomocą można też wygenerować zadania i przypisać je odpowiednim osobom.

Korzyści na trzy sposoby

Team System można "rozdzielić" na 3 główne składowe. Pierwsza to część związana z projektowaniem systemów IT (diagramy logiczne architektury). Zwykle potrzeba taka powstaje, gdy system jest zbyt duży, by jedna osoba mogła ogarnąć wszystkie jego aspekty, a więc, gdy jest to system składający się z wielu usług/aplikacji/serwerów. Jeśli na etapie projektowania diagramów powstał równocześnie "przepis" wdrożenia (ze skryptami, a może nawet konfiguracją, którą trzeba po prostu "wgrać" na docelowym serwerze), to takie narzędzie na pewno jest warte użycia.

Druga składowa to narzędzia dla programisty, w tym zwłaszcza system kontroli wersji i mechanizm zarządzania zadaniami (workitems).

Pozwala on przekazywać zadania w ramach zespołu, jak również na wzajemne informowanie się członków zespołu o postępach prac.

Dodatkowym ułatwieniem dla programisty jest portal, w którym - przynajmniej teoretycznie - znajdują się wszystkie potrzebne dokumenty, np. spisy wymagań, uwagi, zmiany itp. Są to jednak niestety jedynie dokumenty tekstowe, bez struktury i choć można je sformalizować, używając odpowiednich szablonów, nie ma możliwości, by "dołączyć" jakiś element do składowej takiego dokumentu. Tu przewagę ma Borland CaliberRM, który jest dostępny również w wersji dla Visual Studio .Net 2005.

Z punktu widzenia testera użyteczny jest na pewno mechanizm automatyzacji budowy całego rozwiązania. Pakiety tego rodzaju, jak chociażby Draco .Net czy CruiseControl .Net, pozwalające pobrać dane z serwera kodu źródłowego i skompilować je na docelowej maszynie, są od dawna dostępne dla innych "mechanizmów kontroli wersji". Zaletą w przypadku Team System jest to, że można "nałożyć" dodatkowe wymagania do sprawdzenia. Można także zażądać statycznej analizy kodu i wykonania testów jednostkowych. Wyniki automatycznie zostaną umieszczone w hurtowni danych i kostkach OLAP na SQL Server 2005. Tym samym można łatwo podejrzeć postęp prac i przyjrzeć się elementom, które sprawiają najwięcej kłopotów.

Najwięcej korzyści z Team System odniesie menedżer projektu - taki, który nie zajmuje się samodzielnie tworzeniem czy nawet nadzorem nad jego tworzeniem, lecz jest odpowiedzialny za postępy prac i wyniki od strony biznesowej. Taka osoba uzyskuje dzięki Team System dostęp do raportów powiązanych z jakością kodu, postępem prac i innymi ogólnymi miarami pozwalającymi wnioskować o ryzyku, zasobach, kosztach itp. Co więcej, wszystkie interesujące go dane będzie mógł uzyskać nie opuszczając Excela lub Outlooka. Może też wydać polecenie "pobierz listę błędów", jak również samodzielnie zgłosić błędy tworząc zadania. Arkusz Excel może także być narzędziem pracy dla osoby, która zbiera i gromadzi uwagi od użytkowników.