Grzegorz Rycaj: Visual Studio ALM Ryca VySpa z pALMą ;)

Jedną z mocno przydatnych mechanizmów TFSa jest podstawowa kontrola jakości umieszczanych zmian PRZED ich faktycznym zaistnieniem w repozytorium. Mechanizm ten nazywa się Check in policies (luźne tłumaczenie: reguły check-inów) i standardowo z instalacją dostarczone mamy implementacje takich zasad jak np. “wymagany komentarz do check ina”, czy też “wymagane podpięcie work itema”.

1.) Tworzymy projekt…

2.) Dziedziczymy i implementujemy…

[Serializable]
    public class ProjectNameValidator : PolicyBase
    {
        /// <summary>
        /// fraza do weryfikacji w plikach o rozszerzeniu .csproj
        /// </summary>
        private const string _requiredString = "CompanyName";

        /// <summary>
        /// Opis reguły - pojawi się w oknie dodawania reguły
        /// </summary>
        public override string Description
        {
            get { return string.Format("Dokonujemy sprawdzenia, czy wszystkie pliki .csproj zawierają w sobie fragment \"{0}\"", _requiredString); }
        }

        /// <summary>
        /// Informacja pokazana użytkownikowi, gdy nie ma zainstalowanej biblioteki z regułą na swojej maszynie
        /// </summary>
        public override string InstallationInstructions
        {
            get { return "Nie masz zainstalowanej reguły sprawdzenia nazw projektów - proszę pobrać z http://..."; }
        }

        /// <summary>
        /// Wykorzystywane, gdy chcemy edytować istniejącą regułę.
        /// </summary>
        /// <param name="policyEditArgs"></param>
        /// <returns></returns>
        public override bool Edit(IPolicyEditArgs policyEditArgs)
        {
            return true;
        }

        /// <summary>
        /// Główna metoda dokonująca walidacji
        /// </summary>
        /// <returns></returns>
        public override PolicyFailure[] Evaluate()
        {
            var failures = new List<PolicyFailure>();

            // iterujemy po każdym ZAZNACZONYM pliku
            foreach (var file in base.PendingCheckin.PendingChanges.CheckedPendingChanges)
            {
                if(file.FileName.EndsWith(".csproj") && file.FileName.IndexOf(_requiredString) == -1)
                    failures.Add(new PolicyFailure(string.Format("Plik {0} nie zawiera w sobie fragmentu {1}!", 
                                                        file.FileName, 
                                                        _requiredString), 
                                                    this));
            }

            return failures.ToArray();
        }

        /// <summary>
        /// Pokazana administratorowi podczas dodawania reguły dla danego projektu w TFS
        /// </summary>
        public override string Type
        {
            get { return "ProjectNameValidator"; }
        }

        /// <summary>
        /// Szczegółowy opis pokazany administratorowi podczas dodawania reguły dla danego projektu w TFS
        /// </summary>
        public override string TypeDescription
        {
            get { return string.Format("ProjectNameValidator - dokonuje sprawdzenia, czy wszystkie pliki .csproj zawierają w sobie fragment \"{0}\"", _requiredString); }
        }
    }

3.) Instalujemy…

4.) Wymagamy! ;)

Case: Dwa dni temu w ramach jednego z projektów w Billennium przyszedł do mnie kolega z pytaniem o możliwość wyświetlenia dat w szczegółach zadań w TFS. Zadania zostały zaimportowane przeze mnie z MS Projecta i faktycznie daty rozpoczęcia i zakończenia domyślnie nie pokazywały się nigdzie na formularzu zadania ani na liście zadań(screeny poniżej).

Na szczęście z pomocą TFS Power Toolsów udało mi się sprawnie temat ogarnąć i poniżej prezentuję rozwiązanie.

Najpierw widok standardowy, przed rozpoczęciem tweakowania(click na obrazku znacznie ułatwia sprawę;) ):

Jak widać, brakuje gdziekolwiek informacji o oczekiwanych datach rozpoczęcia i zakończenia zadania…

Na szczęście bardzo sprawnie i “na żywym organizmie”(czyli w locie, bez żadnych restartów, zmian w bazie danych i innych cudów) można zmodyfikować Work Itema, żeby zaczął pokazywać pożądaną informację. W tym celu wchodzimy w menu Tools->Process Editor->Work Item Types-> Open WIT from Server i po wskazaniu właściwego projektu i typu Work Itema przechodzimy do zakładki Layout. Na niej w odpowiednim miejscu (ja dla zmyłki w sekcji Classification) klikamy prawym i wybieramy opcję New Control. Następnie wypełniamy właściwości nowododanej kontrolki analogicznie jak na poniższym screenshocie:

Możemy w każdej chwili skorzystać z przycisku “Preview Form”, żeby upewnić się, ze osiągamy zamierzony efekt. Jak już wszystko będzie w porządku wykonujemy zwyczajny zapis(Ctrl+S) i zmiany natychmiast wędrują na serwer. Po przeprowadzeniu takiej przyjemnej i szybkiej akcji, formularz zadania jest wyposażony w dodatkowe pola(u mnie w trybie read only, ponieważ chcę je edytować wyłącznie z poziomu MS Projecta):

Tym samym szybciutko i bez większych problemów udało się pokazać bardzo istotna informację na formularzu.

Dodatkowo naturalnie w Work item queries można w Column Options dodać kolumny Start Date i Finish Date, żeby pokazywać w liście zadań ich terminy. Ale nadal to tylko połowa szczęścia :)

Z lekkim opóźnieniem wracamy do cyklu poznawania Team Foundation Servera :)  Zgodnie z prośbą Andrzeja, dzisiaj kilka słów na temat samej instalacji. Nie chciałbym się jednak powtarzać z publikowanymi przeze mnie już wcześniej materiałami, dlatego najpierw odsyłam Cię, drogi Czytelniku do:

1.) Materiału mojego autorstwa, który ukazał się 22 kwietnia w portalu MSDN:

http://msdn.microsoft.com/pl-pl/library/team-foundation-server-2010—instalacja

Opisuję w nim etap przygotowań do instalacji(wymagania sprzętowe i systemowe), przejście przez proces instalacyjny, razem ze scenariuszem “zaawansowanym” i poświęcam kilka słów możliwościom rozbudowy środowiska np. o dodatkowy serwer aplikacyjny(w celu rozłożenia obciążenia/zapewnienia wysokiej dostępności)

2.) Posta na tym blogu, stworzonego na etapie TFS 2010 BETA2. Tak naprawdę sam proces instalacji nie zmienił się specjalnie od tamtego czasu, więc post też może być przydatny(chociaż traktujmy go jako opcjonalny po lekturze powyższego materiału z MSDN):

http://vsts.pl/post/Instalujemy-TFS-2010-Beta-1.aspx

A teraz kilka słów dodatkowych

TFS 2010 jest pierwszym produktem w serii, posiadającym instalator typu “Next, next, next, thank you”. Wcześniejsze edycje(2005 i 2008) wymagały sporo uwagi i w obu przypadkach zdecydowanie polecam Instalation Guide’y(dostępne pod linkami: 2005 / 2008).

Wizard w 2010 przyjemnie nas prowadzi za rękę przez cały proces, w zasadzie trudno zrobić błąd. Gdy stawiamy pierwszą instalację, radzę nie pchać się w scenariusz zaawansowany, podstawa nam w zupełności wystarczy. Mamy też inną możliwość. Ze stron Microsoftu możemy pobrać TRIAL TFS 2010 w postaci maszyny wirtualnej z zainstalowanymi dla nas odpowiednimi komponentami.

Do pracy z TFS 2010 możemy zaprząc wszystkie wersje Visual Studio 2010 poza Express, jak również większość Visual Studio 2005 i 2008(również poza Express). Wszystko, czego potrzebujemy, to zainstalowany dodatek Team Explorer. Gdybyście nie mieli go w swoim Visual Studio, to poniżej podaję linki:

• Dla wersji 2010: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=fe4f9904-0480-4c9d-a264-02fedd78ab38
• Dla wersji 2008: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=0ED12659-3D41-4420-BBB0-A46E51BFCA86
• Dla wersji 2005: http://www.microsoft.com/downloads/en/details.aspx?FamilyId=46473C2A-BB85-4461-BB27-4792A5DEF222&displaylang=en

Dodatkowo, dla 2005 i 2008 należy pobrać tzw. Compatibility Packi, dostępne pod adresami: 2005 / 2008

No tak, sporo tego, ale tylko w przypadku chęci skorzystania z TFS 2010 z poziomu VS 2005/2008. Przy VS 2010 wszystko powinniście mieć na pokładzie zaraz po instalacji środowiska :) Wymagania doinstalowania dodatków biorą się ze zmian, jakie zaszły w TFS 2010 pod względem organizowania projektów – wg mnie są to zmiany zdecydowanie na lepsze, nieco później w naszym cyklu dowiemy się, jakie to konkretnie różnice.

Tak czy siak, niezależnie od wybranej wersji Visual Studio dążymy do uzyskania widoku zbieżnego z poniższym screenshotem:

Uprawnienia w TFS

TFS pozwala nam zarządzać uprawnieniami na wielu poziomach – zaczynając od poziomu serwera, przechodząc przez kolekcje projektów, projekty, buildy, katalogi(w tym gałęzie), wreszcie na pojedynczych plikach kończąc. Jeśli któryś z poziomów jest dla Ciebie niezrozumiały(np. “kolekcje projektów”) – to nic straconego! Na pewno w ramach naszego cyklu poruszę ten temat.

Zarządzanie uprawnieniami na każdym z poziomów wygląda bardzo podobnie, do czynienia możemy mieć tylko z nieco innymi uprawnieniami(np. na poziomie kolekcji projektów będziemy ustawiali, kto może tworzyć nowe projekty – naturalnie na poziomie projektu takiego uprawnienia już nie będzie :)).

Przykładowy zestaw uprawnień dla kolekcji projektów został zaprezentowany poniżej:

Nie należy się przerażać, widząc te pozycje(nawet jeśli w pierwszej chwili nie wiemy co oznaczają)! TFS zaraz po instalacji ma ustawione pewne standardowe wartości, dzięki którym możecie śmiało zacząć pracę z systemem. A z czasem dojdziecie też do tego, jak sobie zorganizować uprawnienia w Waszym zespole.
Uprawnienia przydzielamy w sposób analogiczny do uprawnień w NTFS – możemy je nadać/odebrać użytkownikowi lub grupie(można je stworzyć “lokalnie” w TFS lub oprzeć o istniejące grupy w Active Directory lub na serwerze TFS – niekoniecznie musi być w domenie). Z praktyki zdecydowanie polecam konfigurowanie uprawnień w oparciu o grupy. Włączenie nowej osoby do zespołu oznacza wtedy dołączenie do odpowiedniej grupy. Naturalnie czasem nie chcemy nadawać pełnych uprawnień, natomiast nadal da się tak rozplanować liczbę grup i ich możliwości, żeby spędzać potem nad nimi bardzo mało czasu :-)

Gdzie faktycznie szukać odpowiednich pozycji konfiguracyjnych? Zawsze tam, gdzie znajdziecie tekst “Security” lub “Group Membership”. Najłatwiej je znaleźć eksperymentując i klikając prawym przyciskiem myszy na różnych elementach w Team Explorerze lub w Source Control Explorerze :-)
Łatwo je też znajdziemy w menu Team –> Team Project Settings / Team Project Collection Settings

• Group Membership – to tu tworzymy sobie nowe grupy i dokładamy do nich nowych członków(uwaga: grupa może się też zawierać w innej grupie!). Jeden użytkownik może naturalnie należeć do wielu grup. Poniżej widzimy konfigurację grupy “Administratorzy projektu”, do której należy obecnie jeden użytkownik.
  Mam jednak możliwość dołożenia grupy TFSowej albo użytkownika/grupy Windowsowej i po wykonaniu takiej akcji wskazani użytkownicy nabiorą odpowiednich uprawnień(jakie to uprawnienia przeczytamy w kolejnej kropce)

• Security – to właśnie tam określamy co może a czego nie dana grupa/użytkownik.
  Jak widać, tutaj też możemy dodać grupę lub użytkownika. Jest to łudząco podobne do tego, co mamy przy zarządzaniu grupami, jednak tutaj mówimy już tylko o stworzeniu na liście nowej pozycji, dla której chcemy nadawać uprawnienia. Na tym ekranie  nie ma mowy o dodaniu nowego członka do grupy “Project Collection Administrators”.

Ważna uwaga odnośnie uprawnień

Opisane powyżej mechanizmy zarządzania uprawnieniami dotyczą wyłącznie części TFSowej – nie propagują się automatycznie na zintegrowane systemy, jak np. Sharepoint Server, czy też Reporting Services. Należy więc oddzielnie ręcznie dodać uprawnienia w odpowiednich miejscach. Tutaj znowu wracam do praktyki zarządzania przez grupy. Jeśli skonfigurujemy sobie sprytnie grupy Windowsowe i wykorzystamy je przy określaniu uprawnień do TFS, Sharepointa i Reporting Services, to potem nadanie uprawnień nowej osobie, czy też zmiana uprawnień dla istniejącego zespołu, zajmie nam dosłownie kilka minut.

Na początek wytłumaczę, dlaczego jednak jeszcze nie piszę o instalacji TFSa(pod poprzednim postem Andrzej zaproponował właśnie napisanie kilku słów nt. instalacji i nadawania uprawnień) – już za moment(w tym tygodniu) na MSDN ukaże się mój artykuł na temat instalacji i wtedy rozpiszę tutaj jego uzupełnienie :)

Poprzednio udało nam się poprawnie podłączyć do TFS. Dzisiaj lecimy więc z przeglądem przystawki Team Explorer w Visual Studio. Dla przypomnienia, ekran, jaki otrzymaliśmy wygląda tak:

Być może ekran, jaki Wam się pojawił jest nieco inny i już za moment dowiemy się, dlaczego. Idąc pokolei, co my tu mamy:

• Ulubione – czyli możliwość przypięcia najczęściej używanych elementów(jednak nie wszystkich). Jak przypiąć? Za momencik się dowiemy :-)
• Work Item Templates – jest to funkcjonalność, którą dostajemy po doinstalowaniu dodatku TFS Power Tools. Bez niego nie zobaczycie tej pozycji. Co nam daje? Pozwala na szybsze i łatwiejsze zarządzanie tzw. Work Itemami, czyli Jednostkami Roboczymi. O Work Itemach porozmawiamy sobie jeszcze nie jeden raz
• Work Items – no właśnie, i znowu Work Itemy ;) mówiąc najprościej, Work Item to porcja informacji, za pomocą której w TFS reprezentujemy informacje o naszym projekcie. Codeplex pozwala nam na przechowywanie Work Itemów, które przyjmują jeden z trzech typów: Funkcjonalność, Zadanie i Problem. Aby dodać nowy Work Item, klikamy prawym przyciskiem myszy na węźle Work Items i wybieramy pozycję New Work Item->Typ.
  Kilka linijek niżej jeszcze powiemy nieco więcej.
• Builds – TFS pozwala na zautomatyzowanie procesu budowania i testowania naszych aplikacji. To właśnie w tym miejscu spędzimy czas konfigurując ten mechanizm.
• Team Members – kolejna funkcjonalność, doinstalowywana ze wspomnianym pakietem TFS Power Tools. Pozwala po prostu na podgląd i zarządzanie współpracownikami w danym projekcie
• Source Control – nic innego, jak repozytorium. Aby rozpocząć pracę z nim, klikamy dwukrotnie właśnie w tym miejscu. W centralnej części ekranu pojawia się widok Source Control Explorer, za pośrednictwem którego możemy przeglądać repozytorium i pobrać kod w odpowiednie miejsce na nasz dysk(prawy klawisz w odpowiednim miejscu i polecenie “Get Latest Version” pozwolą nam wskazać miejsce na lokalnym dysku do którego zostanie pobrany kod):

No dobrze, ale Codeplex kryje malutkie oszustwo… A właściwie nie tyle oszustwo, co po prostu obcięcie funkcjonalności :( Dlatego poniżej wklejam zrzut ekranowy z prawdziwego, pełnego TFSa:

Jakie mamy różnice: przede wszystkim, widzimy dwie nowe gałęzie: Documents i Reports. Instalując Team Foundation Server, mamy możliwość zintegrowania go z MS Sharepoint’em i platformą raportową MS Reporting Services. Team Explorer daje nam szybki dostęp do obu tych miejsc – Documents pozwala na przeglądanie dokumentów składowanych na naszym zespołowym Sharepoincie, a Reports uruchamia w trzech kliknięciach raport dotyczący projektu. Oczywiście zajrzymy do tego za kilka odcinków.

A teraz wracając jeszcze do samego Source Control i pobranego kodu(bo przecież o to nam na początku chodzi, prawda?) – plik solucji możemy odpalać albo od nas z dysku(z podanej wcześniej lokalizacji), albo prosto z Source Control Explorera(SCE). Gdy po dokonaniu zmian chcemy je umieścić w repozytorium, klikamy na odpowiednim miejscu w repozytorium(w następnych odcinkach wyjaśnię, co mam na myśli pisząc o "odpowiednim" miejscu) i wybieramy opcję “Check-in”.

Moje ostatnie prezentacje, spotkania online i dyskusje ze znajomymi pozwoliły mi wyciągnąć wniosek, że mój temat, czyli Team Foundation Server jest w Polsce mało popularny. Przeważnie na pytanie “kto z Was używał kiedykolwiek TFS” ręce podnosi max 10-15% osób. Podobnie było wczoraj podczas Silesian Code Camp, a liczba pytań w trakcie i po mojej prezentacji sprawiły, że pomysł, jaki od pewnego czasu się wykluwał, przeradza się właśnie w działanie :)

Na blogu powstanie nowa kategoria, która jeśli zasłuży, to dorobi się swojego linka w głównym menu ;)) Kategoria będzie nosiła nazwę “Poznaj TFS”, a posty prezentowane w jej ramach będą miały charakter krótkich poradników, ot, takie krótkie piłki ;-)
Liczę na to, że cykl spotka się z zainteresowaniem również starych TFSowych wymiataczy – zachęcam do współpracy, nigdy nie wiadomo, czy nie dowiemy się wzajemnie czegoś od siebie! Tam, gdzie to możliwe, będę się posługiwał codeplexem, co powinno Wam ułatwić przyswojenie i przetestowanie danego tematu. Zaczynamy już dzisiaj, oczywiście od podłączenia do serwera :)

Tworzenie połączenia, logowanie do serwera

Wszyscy na pokładzie? No to startujemy na bogato ;), od razu odpalamy Visual Studio. Dopuszczalne są wszystkie wersje poza Express. Codeplex wspierany jest przez TFS 2010, więc gdybyśmy zechcieli pracować z poziomu Visual Studio 2005 lub 2008, to będziemy potrzebowali tzw. compatibility packów: odpowiednio dla wersji 2005 i 2008. Microsoft rozwijając serwer nie chciał sie po prostu blokować wsteczną kompatybilnością(i bardzo dobrze!), dostaliśmy po prostu paczki do starszych wersji Visual Studio.

Po uruchomieniu Visual Studio szukamy widoku Team Explorer(View->Team Explorer). Jeśli by go tam nie było(w wersjach 2005 i 2008 nie będziecie go mieli na 90%, w wersji 2010 powinien już być), to też niestety trzeba będzie dociągnąć. Znowu wybieramy odpowiedni link dla odpowiedniej wersji: 2005, 2008, 2010. Czysty i goły Team Explorer wygląda tak:

Dodajmy pierwszy serwer! Klikamy w jedyną dostępną ikonkę – tak, to ta pierwsza z prawej z plusikiem. Dostajemy nowe okno, w którym możemy wybrać jeden ze zdefiniowanych serwerów. Ponieważ jeszcze żadnego nie mamy, dodajmy nowy! Klikamy w przycisk servers, a następnie Add. Wpisujemy kilka informacji dotyczących Team Foundation Servera, z którym chcemy się połączyć. Dla uniknięcia problemów polecam wpisanie pełnego adresu URL, czyli w przypadku mojego projektu codeplex: https://tfs.codeplex.com/tfs

Jeśli podaliśmy właściwy adres, zostaniemy spytani o dane dostępowe(chyba, że pracujemy w domenie i system nas rozpozna i uwierzytelni automatycznie). Po ich podaniu mamy możliwość wybrania projektów, z jakimi chcemy pracować. W moim przypadku jest to:

Do tematu kolekcji projektów(lewa kolumna) i samych projektów(prawa) jeszcze wrócimy w kolejnych odcinkach. Kończymy wybór klikając “Connect” i dziękujemy – podłączyliśmy się właśnie do TFS i aż nas korci, żeby zacząć pracę ;-) Aaaale o tym już w następnym odcinku.

Na zachętę tylko screenshot widoku Team Explorer po poprawnym skonfigurowaniu połączenia: