Za długa ścieżka podczas Team Builda, czyli błąd TF10128. Co robić?

Przyjęliśmy w zespole nazewnictwo projektów składające sie z wielu części(Billennium.[Projekt].[Typ:Web\Windows\Obj].[Nazwa własna]). Taki opisowy sposób nazywania projektów pozwala na błyskawiczne zorientowanie się, czego dany projekt dotyczy i generalnie sprawdza się w codziennej pracy doskonale, potrafi jednak doprowadzić do następującego problemu z Team Buildem:

C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(755,5,755,5): error : TF10128: The path C:\Documents and Settings\NetworkService\Local Settings\Temp\[Reszta ścieżki] contains more than the allowed 259 characters. Type or select a shorter path.

Okazuje się(co widać powyżej, na szczęście informacja o błędzie jest jasna), że ścieżka nie może być dłuższa niż 259 znaków. I w sumie jakby się zastanowić, to limit wydaje się być bezpieczny. No właśnie, co zrobić jeśli jednak nie jest 😉

Pierwszy pomysł(zły!): skrócić nazwę samego projektu – skoro inne projekty nie krzyczą tym błędem, to może oznaczać, że w tym konkretnym przypadku trochę nas poniosła wyobraźnia 🙂 Jednak jest to podejście w stylu “Panie doktorze, bolą mnie plecy jak się schylam” – “Proszę się nie schylać”.

Drugi pomysł(dobry!): Chyba niewiele jest osób, którym zależy na tym, żeby źródła dla builda były przechowywane w folderze C:\Documents and Settings\NetworkService\Local Settings\Temp\ (NetworkService możemy sobie zamienić na inny profil – jest zależny od tego, w jakim kontekście odpalimy TeamBuilda). Ta część ścieżki zjada nam 61 znaków, czyli niemalże 25% limitu! Poniżej wyjaśnienie czemu tak się dzieje:

Gdy wejdziemy w managera Build Agentów(w Visual Studio: Build->Manage Build Agents), wyedytujmy dowolny z listy, lub poprośmy o założenie nowego. Pojawi się okienko jak poniżej:

agent_pre

Zmienna $(Temp) w dużej mierze przyczynia się do naszego pięknego przekroczenia limitu. Wystarczy ją zamienić na jakiś inny folder, np C:\Temp:

agent_post

 

Których edycji problem dotyczy?

Z tym problemem spotkałem się podczas pracy z TFS 2008. W TFS 2005 też występuje(co ciekawe, tam limit znaków wynosi 260 :)) ). Idąc prawem serii, TFS 2010 powinien sypnąć błędem przy 258 😉 Starałem się różnymi sposobami wywołać błąd w TFS 2010, ale ostatecznie mi się nie udało. Zdarzało się natomiast, że przy podawaniu dłuższej nazwy, już Visual Studio blokował stworzenie elementu(projektu, builda)…

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.

Windows 2008 pod Windows Virtual PC

vpc

 

Oficjalnie, system Windows 2008 nie jest wspierany w działaniu pod Windows Virtual PC(czyli rozwiązaniu wbudowanym w Windows 7). Ale zainstalować się da 🙂 Problem pojawia się, gdy dodamy integration features(czyli zestaw funkcjonalności np. automatycznie mapujących dyski na maszynie macierzystej lub pozwalających na drag and drop plików do naszej wirtualki. Dodatkowo zawiera elementy optymalizujące pracę naszej maszynki), bo przy starcie mówią, że sorry Winetou, nie jedziemy.

 

 

Znalazłem bardzo proste obejście wymienionego problemu:

1.) w ustawieniach maszyny wirtualnej wyłączamy odpalanie Integration Services przy starcie:

IS_dis

2.) po starcie maszyny(btw. uruchamia się teraz duuużo szybciej) logujemy się i w oknie usług restartujemy usługę Virtual PC Integration Componentes Services Application:

serv_virtpc

3.) Uruchamiamy Integration Services:

 enableIS

 

 

I to w zasadzie tyle. Niestety, nie znalazłem sposobu na automatyczne wykonywanie tej operacji, więc po każdym restarcie wirtualki trzeba powalczyć 😉

Instalujemy TFS 2010 Beta 1

successTak, etap o którym łatwo zapomnieć, a jednak okazuje się być niezbędny: instalacja 🙂

 

Postanowiłem testować na maszynie wirtualnej(pracuję na Win7, więc postanowiłem wykorzystać wbudowanego Windows Virtual PC), na której postawiłem Windows 2008 Standard w wersji x86 – tutaj pierwsze rozczarowanie: Windows Virtual PC wspiera jedynie 32 bitowe wersje hostowanych systemów. Nie uda mi się więc obadać czy i jak działa x64 instalacja TFSa, ale uprzejmie donoszę o pierwszej ważnej zmianie w stosunku do poprzednich edycji: została przygotowana oddzielna wersja dla systemów 64 bitowych!

 

 

 

 

Wymagania systemowe

Znalazłem(oczywiście już po instalacji, ale o tym za chwile;) ), przygotowany przez Mike’a Fourie’ego, bardzo fajny i czytelny diagram, dotyczący wymagań systemowych. Warto zapoznać się z nim, zanim rozpoczniemy instalację.

Planning for TFS 2010

 

No właśnie, instalacje poprzednich wersji TFS(2005 i 2008) praktycznie nie mogły się udać bez Installation Guide’a(przynajmniej początkowo, przy 3 instalacji wiadomo już gdzie nie wolno się rozpędzać). Podczas przygotowywania wirtualnego środowiska pod instalację poszukałem trochę informacji, czy z instalacją “dziesiątki” jest podobnie i wyczytałem, że instalacja została mocno usprawniona, nawet dziecko da radę. No to oczywiście przyjąłem zasadę “to Ty na razie jedź, a ja może później znajdę mapę” i postawiłem SQL Server 2005(bo lżejszy, mniej pamięci będzie pochłaniała moja maszyna wirtualna).

Konkurs dla przeciętnie uważnych czytelników: jaki kolor ma SQL Server 2005 na załączonym powyżej diagramie i co ten kolor oznacza? :-))

Tak, oznacza sciaganie z MSDNu SQL Servera w wersji 2008 😉 Jednak trzeba przyznać ze poza tym jednym wyjątkiem, resztę instalacji dałem już radę przeprowadzić samodzielnie, podpierając się jedynie instrukcją.

Setup screen podczas którego wybieramy co chcemy zainstalować wygląda następująco(jestem już po instalacji, więc posłużę się screenshotem znalezionym w sieci):

install_1

 

ale prawdziwe szaleństwo przychodzi niedługo potem:

install_2

Dostajemy w nasze ręce narzędzie(tak naprawdę przystawkę do mmc), pozwalające na skonfigurowanie naszej instancji TFSa w “wizardowy” sposób. Mamy tu do wyboru:

  • Default Configuration, czyli najprostsza, ale jednocześnie najuboższa opcja jeśli chodzi o konfiguracje. Podajemy tylko konto użytkownika dla WSS, review ustawień i dziękuję 🙂
  • Custom Configuration, czyli konfigurowanie po kolei jak ma działać nasz serwer(ale nadal w formie wizarda). Możemy więc podać inną instancję SQL Servera niż standardowa, określić użytkownika, w którego kontekście będzie chodził nasz TFS, zadecydować czy stworzymy nowy WebSite w IIS, czy dołączymy się do istniejącego, skonfigurujemy raporty etc.
  • Application-Tier Only Configuration, czyli konfigurowanie samej “końcówki”, czyli instancji aplikacyjnej TFS na istniejącej bazie danych(innymi słowy: mamy już zainstalowanego “pełnego” TFSa, ale z uwagi na obciążenie potrzebujemy wprowadzić Load-balancing)
  • Upgrade from a Previous Version – myślę, że wiadomo o co chodzi 🙂

Dodatkowo, jesteśmy w stanie skonfigurować tutaj serwer buildów(przypuszczam, że ta opcja nie pojawi się, jeśli wcześniej w trakcie instalacji nie zaznaczymy checkboxa “Build Service”).

Po udanej konfiguracji pojawia się ekran, którego maksymalnie brakowało mi w poprzednich edycjach:

tfs_config

MMC Snap-in pozwalający w kilku kliknięciach dokonfigurować odpowiednie ustawienia w TFS, pozwalający na ogarnięcie jednym spojrzeniem co się dzieje z naszym serwerem, ustawienie uprawnień… Brawo dla twórców! Postaram się w kolejnym odcinku opisać, co dokładnie daje nam ten snap-in.

 

Podsumowując, muszę powiedzieć, że poza jedynym problemem z SQL Serverem, który oczywiście stworzyłem sobie sam(żeby nie było zbyt nudno), instalacja przebiega bardzo przyjemnie. Sam wizard i potem Administration Console to juz mistrzostwo świata. Odniosłem też wrażenie, że proces instalacji TFS 2010 przebiega szybciej niż w przypadku poprzedników. No, zaczyna się obiecująco… zobaczymy co będzie dalej! 🙂

3… 2… 1… Go! :-)

droga_small

 

No tak, nie przypuszczałem że i ja kiedyś zacznę… Oto pierwszy wpis na moim nowoutworzonym blogu, na którym chciałbym pisać o moich zmaganiach głównie z Team Foundation Serverem(chociaż mam nadzieję, że nie skończy się tylko na tym temacie).

 

A dlaczego chcę się skoncentrować głównie na tym obszarze?

Od pierwszej wersji TFS(czyli 2005), stałem się mocnym zwolennikiem tego “kombajnu”. Niektórzy twierdzą, że nie zna życia, kto nie służył w marynarce korzystał z SourceSafe’a… No to ja nie znam życia 😉 Ale używałem SVN i CVS i muszę powiedzieć, że nie wyobrażam sobie dzisiaj pracy bez TFS(chociaż Source Control jest tylko jedną z wielu funkcjonalności, które stanowią o sile systemu) i powrotu do tamtych systemów kontroli wersji.

Ostatnio MS wypuścił wersję Beta kolejnej odsłony, czyli Team Foundation Server 2010 i właśnie to wydarzenie zmotywowało mnie, aby rozpocząć opisywać co nowego oferuje TFS(poza tym wiele źródeł pisało o tym co nowego w Visual Studio 2010, natomiast o Team Foundation Serverze pisze się nieco mniej – co w sumie zrozumiałe).

Mam nadzieję, że uda mi się chociaż w minimalnym stopniu spopularyzować ten bogaty zestaw narzędzi. Tak więc 3… 2… 1… startujemy!