Team Foundation Administration Console: Team Project Collections

tfs_configNa koniec wpisu o instalacji TFS 2010 Beta obiecałem, że przyjrzymy sie bliżej pierwszej nowości, którą zauważamy tuż po zainstalowaniu: Team Foundation Administration Console.

 

Czym jest to narzędzie? Interfejsem graficznym, zbierającym w jednym miejscu wiele funkcjonalności, związanych z naszym TFSem. Dodatkowo możemy skonfigurować takie rzeczy jak ustawienia powiadomień(serwer SMTP oraz z jakiego adresu będą wychodziły maile) – w poprzedniej wersji trzeba było ręcznie zmieniać w web.configu skrzętnie schowanym w program filesach 😉

Dodatkowo możemy tu zarządzać grupami TFSowymi(coś, co dotychczas robiło się chyba wyłącznie z poziomu Visual Studio – Web Access na to nie zezwalał). Dla mnie nigdy nie stanowiło to problemu, jako że VS to moje codzienne narzędzie pracy, ale zakładając, że mamy w firmie admina, zajmującego sie zarządzaniem użytkownikami i przydzielaniem im odpowiednich uprawnień, nie będziemy już musieli zmuszać go do używania VS. Ma swoje ukochane MMC 😉

Ponadto w dosłownie 5 kliknięciach możemy zmienić użytkownika, w którego kontekście jest uruchomiony TFSa(tak naprawdę zmienia się Identity w IIS dla puli w kontekście której chodzi Web Site – nie jest to więc nic nowego, mamy po prostu wiele rzeczy w jednym oknie, zamiast szukać ich po różnych miejscach w systemie). Z jednej strony możnaby powiedzieć, że “no faktycznie, kontekst użytkownika to ja zmieniam codziennie” ;), ale z drugiej jest tu coś zdecydowanie ważniejszego: odpalamy sobie naszą konsolkę administracyjną i widzimy co się dzieje. Ten sam argument przemawia za pozycją Team Foundation Build. Znajdują się tam informacje o kontrolerach i agentach buildów. Tym podobnych małych, ale przyjemnych usprawnień jest tutaj całkiem sporo. Chciałem się jednak skupić głównie na absolutnej nowości w tej wersji TFS:

Team Project Collections

W TFS 2005/2008 wszystkie projekty znajdowały się w jednym wspólnym repozytorium, repozytorium natomiast korzystało z jednej bazy danych. Prawdę mówiąc, nie stanowiło to dla mnie nigdy większego problemu, jednak zastanawiałem się, jak sytuacja wygląda, gdy mamy w source control kilkadziesiąt projektów – jeśli chodzi o zarządzanie nimi, backupowanie, ratowanie w razie potrzeby(opieramy się o jedną bazę danych!). “Dyszka” wychodzi na przeciw tym(i innym) problemom z funkcjonalnością pt. “Team project Collections”. Każde TPC to jednostka organizacyjna, odseparowana od pozostałych TPC. Jesteśmy w stanie definiować zupełnie inne uprawnienia w ramach jednej kolekcji niż w innej, zezwalać na dostęp innym użytkownikom, aż wreszcie – przechowywać odseparowane projekty.

Co więcej, dla każdego TPC jesteśmy w stanie zdefiniować oddzielną bazę danych, o którą będzie się opierało. Możemy sobie zarządzać każdą kolekcją niezależnie od pozostałych, na określony czas wyłączać(podając informację, która pojawi się komuś, kto podejmie próbę pracy z dana kolekcją). Przechowujemy kod, który niezależnie branchujemy, mergujemy, etc. Jaka jest podstawowa zaleta z mojego punktu widzenia? Przede wszystkim: porządek! Mając –naście albo –dziesiąt projektów(mam na myśli projekty TFSowe, nie .csproje 🙂 ), na pewno da się wyróżnić takie grupy, które są od siebie zupełnie niezależne.

W skrócie można powiedzieć, że source control w każdej instancji TFS 2005 i 2008 to coś w rodzaju pojedynczego Team Project Collection.

team_collections

A tak wygląda teraz okno Team Explorera:

teamexplorer 

 

Zwróćcie uwagę, że po lewej stronie wybieramy TPC, w ramach którego chcemy pracować. Wybrałem akurat pozycję, która jest offline z ustawionym customowym komunikatem. Mam tylko jedną małą uwagę: ginie w tak małym okienku przy tak dużej ilości tekstu wprowadzającego! Przypuszczam, że jako użytkownik nie doczytałbym do tego miejsca. Albo bym od razu kliknął “Retry”, albo zaczął szukać błędu TF31001 w sieci 😉

Przy organizowaniu projektów w kolekcje trzeba jednak być bardzo ostrożnym – zły podział może nas sporo kosztować: między kolekcjami nie można uruchamiać zapytań na Work itemy, nie można łączyć ze sobą Work Itemów, nie ma możliwości tworzenia branchów pomiędzy TPC, etc. Tak jak napisałem powyżej, są to odseparowane od siebie jednostki organizacyjne.

Lab Management

Na koniec chciałbym odnotować jeszcze jedną ciekawą pozycję, której nie miałem jeszcze okazji przetestować z uwagi na ograniczone zasoby sprzętowe, ale zapowiada się niezwykle ciekawie: Lab management. Wyobraźmy sobie, że pracujemy nad wielowarstwową aplikacją. A teraz wyobraźmy sobie, że chcemy ją testować 🙂

Postawienie wszystkich warstw na wspólnej maszynie może spowodować, że testy nie wykryją jakiegoś błędu. Bylibyśmy spokojniejsi, gdyby udało się odtworzyć środowisko produkcyjne(na tyle, na ile to możliwe oczywiście). Niestety przygotowanie oddzielnej maszyny dla każdej warstwy jest kosztowne(co najmniej czasowo).

Podobno Lab Management ma pozwolić na przygotowanie środowiska testowego(opartego o maszyny wirtualne) w kilkadziesiąt minut.

 

Na koniec… jedna uwaga 😉

Zaczęliśmy od Administration Console, to też skończmy 🙂 Zwróciło moją uwagę dość mocne zużycie pamięci. Mniej niż 50 mega zaalokowanego ramu nie widziałem, udało mi się natomiast przekroczyć 80… Wiem, że przy ilości pamięci, jaką dzisiaj dysponują serwery, nie jest to ogromny problem, niemniej jednak jest to dziwne.

No Comments

Post a Comment

Time limit is exhausted. Please reload CAPTCHA.