Ponad 4 miesiące po premierze Visual Studio .Net 2005 Microsoft udostępnił oparte na nim rozwiązanie do pracy grupowej nad projektem informatycznym - Team Server Foundation.

W skład Team Server Foundation (TSF) wchodzi wiele zintegrowanych ze sobą rozwiązań. Najważniejszy z nich to oczywiście Visual Studio .Net 2005 Team System (VSTS 2005), który dostępny jest w czterech edycjach dostosowanych do poszczególnych ról w projekcie. TSF jest rozwiązaniem obejmującym wszystkie role w projekcie i tworzącym wraz z SQL Server 2005 i SharePoint Portal Server 2003 platformę do pracy grupowej nad zadaniami w projekcie (tzw. workitems). SQL Server 2005 jest także oczywiście repozytorium kodu i stanowi podstawę dla systemu kontroli wersji.

Usługi Reporting Services serwera SQL Server 2005 są wykorzystywane w TSF jako narzędzie do generowania i pokazywania wszelkiego rodzaju zestawień. Ponieważ przeglądarka raportów bazuje na ASP .Net, łatwo została zintegrowana ze specjalnie przygotowanym portalem Windows SharePoint Services, który także jest standardowym elementem infrastruktury Team System. Dzięki temu bez uruchamiania środowiska IDE można zobaczyć, ile wpłynęło nowych zgłoszeń o błędach, ile jeszcze workitems trzeba wykonać itp. Portal ten zawiera także wszelką związaną z projektem dokumentację, którą można edytować, wersjonować, przeglądać historię wprowadzanych zmian itp. Jest też wsparcie dla komunikatora Messenger (sprawdzanie dostępności uczestników projektu).

Wybierz swoją metodykę

W trakcie definiowania nowego projektu należy w pierwszym rzędzie wybrać szablon/wzorzec metodologii. W standardowej instalacji dostępny jest wzorzec MSF Agile (zgodne z MSF 4.0), przeznaczony dla "szybkich" projektów, w których nie jest wymagana formalna dokumentacja procesowa oraz bardziej sformalizowany CMMI. Wielu partnerów Microsoft zdefiniowało jednak własne wzorce, często z dodatkowymi narzędziami dostępnymi z poziomu Visual Studio .Net. Na przykład firma Conchango zdefiniowała wzorzec pozwalający zoptymalizować Visual Studio .Net 2005 Team System pod kątem procesu zgodnego z metodyką Scrum.

Taki własny wzorzec do TSF może definiować np. własne dodatki do IDE, skróty, dodatkowe kwerendy (raporty, widoki danych), narzucać kolejność wprowadzania informacji itp. Poszczególne pozycje na liście workitems można także rozbudowywać o dodatkowe elementy (zakładki, pola), albo też dodawać nowe predefiniowane zapytania, definiować instancje (czyli roadmap), będące spisem zadań do wykonania w ramach projektu.

Definiując iterację, czyli proces przygotowania kolejnej wersji aplikacji, można w TSF wymagać wykonania pewnych określonych czynności. Definiowana może być nawet forma "notatki" wymaganej przy procesie dodawania/aktualizacji źródła do repozytorium. Można także zdefiniować wymaganą strukturę zespołu, np. wymusić pojawienie się w projekcie roli testera, albo osoby odpowiedzialnej za szerszy program lub produkt itp.

Dostarczane przez Microsoft standardowe szablony projektów także nadają się do modyfikowania. Na podstawie wzorca standardowego można stworzyć nowy szablon, w którym pewne założenia lub etapy zostaną narzucone, bez możliwości traktowania ich fakultatywnie. Na portalu GotDotNet dostępne jest narzędzie Visual Studio Team System Customization Toolkit przeznaczone do graficznego zarządzania konfiguracją projektów w TSF. Za jego pomocą można definiować własne typy workitems i nowe listy globalne.

W wielu sytuacjach warto zmodyfikować bazowe wzorce w TSF i dostosować do wymagań konkretnego projektu/firmy. Temu celowi służy Process Template Editor - dodatek, który pozwala edytować wzorce "procesowe" dostarczane w ramach VSTS 2005. Taki wzorzec jest po prostu rozbudowanym dokumentem XML, opisującym uprawnienia, zależności, pola, łącza do dokumentacji procesu itp. Dodatek jest już stabilny i dostępny na licencji Shared Source.

Wszystko wokół zadania

Podstawową jednostką pracy w VSTS 2005 jest workitem. Może nim być m.in. zadanie, zgłoszenie błędu, scenariusz użycia, opis związanego z projektem ryzyka, czy też komentarz na temat jakości. Pozostańmy przy tłumaczeniu jednostki zadanie. Standardowe atrybuty zadania to osoba zgłaszająca i osoba, której zadanie zostało przydzielone, a także zestaw atrybutów dotyczących statusu (np. sprawdzane, potwierdzone przez testera, załatwione itd.). W przypadku metodologii CMMI pojawia się dodatkowy typ zadania - przegląd (review), który tak naprawdę jest sformalizowaną notatką ze spotkania.

Dzięki Windows Sharepoint Ser-vices można organizować spotkania offline, bez fizycznej obecności. W takim przypadku uczestnicy wspólnie edytują jeden workitem. W ramach takiego portalu można tworzyć dodatkowe zadania, dodawać łącza, np. do zbioru zmian (wersji) kodu, wskazywać wyniki testów itp. Można też dodać po prostu dokument lokalny, który po publikacji zadania zostanie umieszczony w odpowiednim miejscu na portalu WSS. Zadania do portalu można dodawać z poziomu programów Excel lub Project.

Każdemu zadaniu przypisana jest historia zmian, wiadomo więc kto i kiedy wprowadzał zmiany w poszczególnych atrybutach. Co więcej, taka historia jest gromadzona w hurtowni danych w SQL Server 2005 i można ją później poddać analizie, np. w celu sprawdzenia skali zmian lub postępu w projekcie. W tym drugim przypadku można zdefiniować (lub zmienić domyślne) mapowanie pomiędzy polami w projekcie a polami w VSTS 2005. Potem na podstawie projektu w Project można wygenerować początkowy zestaw zadań dla zespołu. Gdy projekt już trwa, w dowolnym momencie można też wykonać operację odwrotną, czyli porównać zawartość zadań z założeniami wpisanymi do harmonogramu w Project.

Większość obiektów powstających w środowisku TSF jest powiązana z konkretnym projektem. Czasami takie podejście może być sensowne, np. gdy chcemy, by projekt bazował na konkretnej wersji biblioteki i miał ją niejako na wyłączność, niemniej na pewno nie wyczerpuje to potrzeb. Wyraźnie brak tu mechanizmu, który pozwalałby definiować związki obiektów pomiędzy projektami, np. w sytuacji gdy firma rozwija pewien framework używany przez różne systemy.

Można co prawda tworzyć "odgałęzienia" w kodzie źródłowym pomiędzy różnymi projektami, ale już np. błędy zgłaszane w takim odgałęzieniu będą przydzielone tylko do programistów w ramach takiego projektu, a nie do frameworka. Nie ma też mechanizmów odzwierciedlających współdzielenie zasobów. Powstało już za to narzędzie pozwalające przenosić zadania między projektami. Dzięki temu można na przykład błąd, który powstał w aplikacji "przesłać" do zespołu zajmującego się frameworkiem, na którym ta aplikacja się opiera. W planach jest wprowadzenie synchronizacji, która pozwoli, by zadanie mogło być współdzielone przez wiele projektów.

Nowa kontrola wersji

Microsoft w zarządzaniu kodem źródłowym przez długi czas opierał się na narzędziu SourceSafe, które jako repozytorium wykorzystywało system plików. Pakiet ten miał wiele innych ograniczeń, np. domyślnie działał w trybie blokowania z wywłaszczeniem, które jest do zaakceptowania jedynie przy niewielkiej skali projektu lub gdy praca jest tak podzielona, że właścicielem jednego pliku jest jedna osoba (i zwykle tylko ona go zmienia). Co więcej, do współpracy wykorzystywany jest standardowy folder sieciowy, co utrudnia współpracę poprzez typową sieć WAN. Co prawda w Source Safe w Visual Studio .Net 2005 pojawił się mechanizm usługi Web, który pozwala na zdalny dostęp do repozytorium, ale główne mechanizmy nie uległy zmianom.

W TSF dostępny jest zupełnie nowy mechanizm kontroli wersji oparty na SQL Server 2005 i Web Services. Każda operacja może mieć przypisany zestaw polis, które w określonych przypadkach mogą zawierać odwołanie do kodu .Net (można je definiować podczas definiowania wzorca/szablonu przy zakładaniu projektu). Definiowanie gałęzi wersji polega nie na fizycznym kopiowaniu plików, lecz na opatrywaniu kodu "etykietami".

Dostarczane wraz z pakietem SDK oficjalne API pozwala na bezpośrednią manipulację zawartością repozytorium - bazy danych. Można też po prostu sięgnąć do konkretnych tabel. Ze względu na ryzyko uszkodzenia repozytorium odradzałbym jednak tę drugą metodę.

Aby kod mógł być zatwierdzany w innej gałęzi, musi spełnić zdefiniowane wcześniej warunki. Na przykład można wymagać, by przejście pomiędzy gałęzią "testową" a "produkcyjną" było możliwe tylko wtedy, gdy skompilowana aplikacja przejdzie wszystkie testy jednostkowe. Zasady mogą zależeć od tego, kto wysyła plik, do jakiej gałęzi, czy nawet jakiego folderu dotyczy.