TFS Power Tools i modyfikacja Work Itema

06
lip/11
0

gears

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 :)



Dostęp do TFS przez SVN? SVNBridge i przybij żółwika! :-)

14
lis/09
1

conflict

Jeśli używasz na codzień Team Foundation Servera, ale na przynajmniej jeden z poniższych punktów odpowiadasz kiwając ze zrozumieniem głową, to z pewnością dalsza część wpisu może Ci się wydać interesująca:)

 





a) Pracowałam/Pracowałem z CVS/SVN. Lubię klienta, np. Tortoise'a, z którym się dotychczas łączyłem(-am) z repozytorium i na razie chcę przy nim zostać!

b) W naszym zespole mamy osoby niekorzystające z Visual Studio, ale chcące mieć możliwość pracy z repozytorium kodu.

c) Zastanawiam się, czy zawsze muszę odpalać Visual Studio, żeby zrobić Check Ina?

Niedawno dowiedziałem się o ciekawym projekcie, pozwalającym na dostęp do repozytorium Team Foundation Servera, za pośrednictwem klienta SVNowego. Mam tu na myśli projekt SVNBridge, rozwijany na licencji Microsoft Public License. Najnowszą wersję, wraz z kodem źródłowym możemy znaleźć na Codeplexie, pod adresem http://svnbridge.codeplex.com/.
Pomysł jest zasadniczo prosty: komendy SVN są tłumaczone na polecenia TFSowe i vice versa, dzięki czemu komunikacja może mieć miejsce. Naturalnie oba repozytoria rządzą się swoimi prawami, więc nie wszystko, co lubimy w TFS lub SVN będzie tutaj bezproblemowo działało. Ale generalnie komunikacja jest możliwa.

Instalacja

Opcje instalacji mam dwie: albo odpalamy sobie plik exe(np. u siebie na maszynie developerskiej), który nasłuchuje na podanym przez nas porcie i stanowi proxy w komunikacji z TFS, albo możemy postawić proxy w postaci aplikacji w IIS. Poniżej zaprezentowałem na kilku screenach tą drugą opcję, czyli hostowanie w IIS. Odpalenie SVN Bridge jest na maxa proste. Aha, pokazuję już na przykładzie TFS 2010 beta2 - więc od razu potwierdzam, że działa, choć nie do końca kompletnie :(

1.) Z codeplexa ściągnąłem paczkę SvnBridge-Server.zip. Na serwerze, na którym mam TFS, rozpakowałem pliki do katalogu C:\inetpub\wwwroot\SvnBridge\ i w pliku web.config zmieniłem wskazanie "TfsUrl" na "http://localhost:8080/tfs" (w katalogu wirtualnym tfs stoi u mnie tfs 2010).

2.) Dodałem aplikację do IIS, jako katalog wirtualny(żeby nie rezerwować oddzielnego portu). Aha, pula, w kontekście której odpalamy powinna mieć ustawiony pipeline w trybie Integrated(w przypadku IIS 7 naturalnie)

3.) Zrobiłem tortoisowy check out z adresu http://tfsserver:8080/SVNBridge/[SciezkaDoProjektu]

Tym sposobem pobrałem kod z TFS za pośrednictwem klienta SVN. Naturalnie mógłbym zrobić checkin(commit) i co ciekawe, mógłbym na końcu komentarza dodać linijkę
work items: 1,2,3

i podobno(nie przetestowałem tego jeszcze) mój check in zostałby skojarzony z work itemami 1, 2 i 3

Problemy

Niestety, nie mam chwilowo dostępnego TFS 2008, żeby sprawdzić, czy tam też występuje ten problem, ale przy TFS 2010 Beta 2 nie jestem w stanie uruchomić Repo Browsera! :( Tzn. pyta się ze 200 razy o login i hasło, żeby w końcu powiedzieć, że e-eee, nie jedziemy... Ale na liście funkcjonalności wsparcie dla repo browsera widnieje, więc jest szansa, że z TFS 2008 będzie śmigać.

Podsumowując - SVNBridge to bardzo fajny projekt, ratujący w przypadku wystąpienia sytuacji a, b i c(i nie tylko) ze wstępu do tego posta. Polecam!



Work Itemy i MS Project, czyli problem z odświeżaniem dat

07
sie/09
0

header_imgJeśli zdarzyło Ci się kiedykolwiek importować zadania z TFS do Projecta, to ten post może być dla Ciebie. Jeśli kiedykolwiek zastanawiałeś się, dlaczego podczas importu standardowo gubione są ustawienia dat, to ten post z całą pewnością jest dla Ciebie! :-)

 

Na codzień pracuję z projectem i z niego publikuję zadania do TFS. Ostatnio kolega chciał zassać sobie do nowego pliku Projecta aktualne zadania, żeby mieć możliwość śledzenia, co się kiedy kończy i kiedy powinny być dostępne nowe funkcjonalności do testowania. I co się okazało?
Work Itemy oczywiście może pobrać, pobierze się ich długość(czas trwania), ale wszystkie ustawią mu się na starcie projektu – czyli standardowo na dzień utworzenia pliku. Dlaczego tak się dzieje? A dlatego, że mapowania TFS<->Project są tak skonfigurowane, że StartDate i FinishDate się mogą publikować na linii Project->TFS, ale nie odświeżają się na linii TFS->Project? I już :-)

Tak wyglądają zadania zaprojektowane w projekcie i wysłane do TFS:

 

project_norm

 

A tak wyglądają zassane do nowego projecta z TFS:

 

project_import

 

Co więcej, jeśli ściągniemy do Projecta Work Itemy, nic nie zmienimy i cykniemy Publish, to zgodnie z poprzednim zdaniem, uda się je zaktualizować na TFS, przy okazji przestawiając wszystkim daty wykonania :)) Cool, prawda?

Ale na szczęście…

… da się coś z tym zrobić. Trzeba zmodyfikować wspomniane domyślne mapowania. Służy do tego narzędzie TFSFieldMapping, instalowane razem z Team Explorerem(znajduje się w katalogu <X>:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE). Składnia jest następująca:

TFSFieldMapping upload|download <server_URL> <team_project> <file_path>

Pobrany niezmodyfikowany plik wygląda następująco:

 

 

Jak widać, pola Microsoft.VSTS.Scheduling.StartDate oraz Microsoft.VSTS.Scheduling.FinishDate mają ustawiony atrybut PublishOnly na “true”, co w efekcie powoduje działanie opisane powyżej. Wystarczy zmienić wartości w obu przypadkach na false, ponownie skorzystać z narzędzia TFSFieldMapping(tym razem używając opcji upload) i… work itemy pobierane z TFS będą poprawnie odświeżały swoje daty! :-)



Zarządzanie Work Itemami w TFS

27
lip/09
0

predefinedqueries Jeśli chodzi o Work Itemy, omówiłem już przede wszystkim czym są, jakie nowe mechanizmy, które ich dotyczą, pojawiły się w TFS 2010 oraz opisałem nowe typy Jednostek Roboczych w MSF v5, opublikowanym wraz z TFS2010 beta1. Pomijałem jednak dotychczas temat szerszego zarządzania Work Itemami, ponieważ chciałem poświęcić temu osobny wpis. Oto i on :-)

Wyszukiwanie

Zacznijmy przede wszystkim od przejrzenia dostępnych sposobów wyszukiwania interesujących nas Work Itemów. Tworzenie zapytania o zestaw jednostek roboczych, które spełnią zadane przez nas warunki, jest banalnie proste: Klikamy prawym przyciskiem myszy na pozycji Work Items w drzewie pod team projectem i wybieramy pozycje “Add query”:

 

addquery

 

Pojawia się okno tworzenia zapytania. Moim zdaniem, jest ono maxymalnie intuicyjne. Możemy dodawać kolejne warunki w kolejnych rekordach grida, łącząc je warunkami logicznymi. Co więcej możemy grupować kolejne warunki, przez co zapytanie A and B or C można pogrupować jako (A and B) or C albo jako A and (B or C) – co może mieć istotny wpływ na zwrócone wyniki :) Naturalnie, możemy w ogóle nie grupować i zdać się po prostu na kolejność działań.

 

query1

 

Powyższy screenshot pokazuje, jak wygląda narzędzie do tworzenia warunków naszego zapytania oraz jak “dodać nawiasy”(zaznaczamy odpowiednie warunki, klikamy prawym na jednym z nich, a następnie z kontekstowego menu wybieramy pozycję “Group Clauses”). Po dodaniu odpowiednich warunków wciskamy F5 i otrzymujemy wyniki spełniające nasze kryteria. Naturalne jest, że możemy zechcieć zapisać zapytanie, żeby nie budować go za każdym razem od nowa – klasyczne Ctrl+S i pojawia nam się takie oto skomplikowane, przerażające okienko:)

 

savequery

 

Zacznę od opcji najłatwiejszej, czyli zapis do pliku. Nic nadzwyczajnego, możemy zapisać zapytanie w formacie wiq – jego zawartość do XML.
Znacznie ciekawsze jest jednak zapisanie zapytania na serwerze – możemy wtedy z dowolnego miejsca wykorzystać utworzone wcześniej zapytanie, co może być przydatne np. podczas pracy z TFS Web Access’em. W dalszej części tego wpisu poznamy jeszcze inne zastosowania. Zapytanie możemy zapisać w dwóch miejscach: albo widocznym tylko dla nas, albo dostępnym dla wszystkich członków projektu. Wprawdzie nie jest to jakieś “big wow”, ale naprawdę bardzo przydatna funkcjonalność, pozwalająca na utrzymanie porządku w projekcie(nie wnikam, jak o swoje bieżące Taski dbają poszczególni członkowie zespołu – ważne, żeby potworzyli takie zapytania, które sami rozumieją. A przy tym nie zaśmiecili wspólnego kontenera zapytań).

Co więcej, mamy możliwość skorzystania z predefiniowanych zapytań(ich lista, dostępna w MSF for agile software development v4.2, widoczna na obrazku tuż pod tytułem posta). Jak widać, jest związana z typami Jednostek Roboczych, dostępnymi w ramach procesu – stąd, jak nietrudno się domyślić, lista dla nowego MSF będzie nieco inna. Tak czy siak, mamy tu podstawowe zapytania, które twórcy procesu uznali za potrzebne dla wszystkich i umieścili jako standard. Nie jest to jednak żadna czarna magia – powstały one ma takiej samej zasadzie jak opisana powyżej :-)

Śledzenie

Work itemy śledzić możemy na wiele sposobów: najprostszy to naturalnie działanie z poziomu Visual Studio. Zespół odpowiedzialny za rozwój TFSa dał nam jednak więcej możliwości. Możemy użyć np. TFS Web Accessa(czyli dostęp przez przeglądarkę). Jak widać na poniższym obrazku, możemy korzystać z tych samych zapytań, które sobie skonfigurowaliśmy w Visual Studio.

 

 

Co więcej, możemy sobie stworzyć nowe zapytanie(lub wyedytować istniejące) w sposób bardzo zbliżony do tego, który prezentowałem powyżej, w Visual Studio.

 

webacc_qeditor

 

Web Access jest jednak najrzadziej używanym przeze mnie dostępem, chociaż nie ukrywam, że dla osób spoza zespołu developerskiego w firmie, ten sposób jest bardzo wygodny(no bo dać im Visual Studio to jak zainstalować szyberdach do malucha… ;) ).

Najczęściej natomiast używam MS Projecta. Wybieramy sobie zapytanie, którym chcemy pobrać Work Itemy, po zwróceniu wyników wybieramy, które pozycje konkretnie nas interesują i wuala: możemy sobie dziergać :)

 

 

Po skończonej pracy, korzystając z opcji Publish wysyłamy zmiany do Servera. Naprawdę praca jest bardzo wygodna, a gdy teraz, w nowej wersji, dodano możliwość tworzenia hierarchii zadań, to powinien być już w ogóle total wypas :)

Przedostatnim sposobem, który chciałbym omówić jest dostęp z Excela – wiadomo, narzędzie jest niezwykle popularne, a przy tym doskonale się tutaj nadaje, więc nie można było go pominąć. Dla mnie wszystko, czego potrzebuje ma Project + Visual Studio, ale czasem zdarza się, że nie chce odpalać VS i z poziomu Excela ciułam sobie coś na TFS ;) Nie będę już wklejał screenshota, bo nic wielkiego się tu nie dzieje. Ponownie, po skończonej pracy możemy zapisać zmiany jednym szybkim kliknięciem w “Publish”.

Na koniec zostawiłem furtkę, jaką dla nas, developerów zostawiono. Mianowicie – TFS wystawia cały zestaw Web Service’ów, za pośrednictwem których możemy sobie na nim pracować. Przygotowano oczywiście kilka WebMethod, z których można skorzystać, żeby dobrać się do Work Itemów. Tak więc możemy napisać sobie dowolny własny tool, służący np. do operacji na Jednostkach Roboczych. Postaram się poświęcić temu tematowi osobny wpis(albo nawet całą serię, bo to duży obszar :) ).

Co tam Panie w nowej wersji?

Na koniec naturalnie zaglądniemy do TFS 2010, żeby sprawdzić, co tam nowego słychać w temacie wyszukiwania i śledzenia Work Itemów. Sam mechanizm Team Queries/My Queries pozostał ten sam. Sposób wyszukiwania – ten sam. Co więc jest nowego? Sposób wyświetlania. Z uwagi na możliwość tworzenia hierarchii Tasków, możemy je wyświetlić w strukturze drzewiastej. Jak widać, wielkie zmiany nie zaszły… Ale generalnie – czy powinny zajść?

 



Ograniczenia nazw w Team Foundation Serverze

18
lip/09
0

Znalazłem na MSDNie ciekawy artykuł, opisujący ograniczenia i zasady nazewnictwa różnych obiektów w TFSie. Można się tu dowiedzieć nie tylko jak długa może być np. nazwa Team Projectu, czy też nazwa grupy, ale też jaka jest maksymalna wielkość Szablonu projektu(2GB). Najciekawsze jednak dla mnie są ograniczenia dotyczące wielkości załączników do Work Itemów(aż wstyd że nie wiedziałem dotychczas, ale w sumie dodając głównie screenshoty ciężko przekroczyć limit :P). Domyślna granica to ~4 MB, ale można ją zwiększyć aż do 2 GB.

Doskonałe źródło informacji, pozwalające rozwiązać głupie problemy(np. użycie niedozwolonego znaku w nazwie projektu), które jeśli nie są dobrze opisane przez pojawiający się błąd, to można stracić na nich sporo czasu.

Polecam :)



Work items, czyli jednostki robocze

07
lip/09
0

wi_menu W poprzednim wpisie wspomniałem o work itemach. Polskie (oficjalne?) tłumaczenie to “jednostki robocze”. Ręka w górę, kto jest w stanie intuicyjnie wywnioskować z angielskiej, lub z polskiej nazwy, o co w ogóle chodzi :) Być może brzmi znajomo dla kilku osób, związanych z project managementem. Wg słownika serwisu 4pm.pl, Work item to część projektu, która może zostać jednoznacznie wydzielona i zidentyfikowana. Ok, fajna definicja, ale nadal może brzmieć obco ;)




Work item w kontekście TFS

Dlaczego w ogóle poruszam ten temat? Team Foundation Server wykorzystuje Jednostki robocze do przedstawiania jakiegoś fragmentu informacji o projekcie. Dla przykładu, metodyka MSF for agile software development v4.2 , której template otrzymujemy razem z instalacją TFS 2008, zaleca wykorzystywanie następujących jednostek roboczych: Scenariusz(Scenario), Wymagania dot. jakości – coś na kształt wymagań niefunkcjonalnych(Quality of service requirement), Zadanie(Task), Ryzyko(Risk) oraz Błąd(Bug). Możemy więc np. kontrolować postępy prac za pomocą zadań, testerzy mają możliwość zgłaszania błędów za pomocą jednostki typu błąd, czy też w łatwy sposób powinniśmy wyszukać scenariusze, których jeszcze nie zbudowano. Ponadto jesteśmy w stanie wygenerować sobie raport prezentujący np. liczbę(albo przyrost) błędów w czasie trwania projektu. Niesłychanie przydatną funkcjonalnością jest również powiązanie check-ina(czyli wrzucenia kodu do repozytorium) z jakąś jednostką roboczą, dzięki czemu możemy wyciągnąć później wszystkie zmiany w kodzie, związane z danym, albo rozwiązujące błąd.

 

Wymieniłem powyżej 5 różnych typów(kategorii) work itemów. Co jednak odróżnia jeden typ od drugiego, po co wprowadzono w ogóle taki podział? Zalet jest kilka:

  • przede wszystkim uporządkowanie w celu zarządzania nimi
  • każdy typ posiada swój własny workflow(jakie może przyjmować stany i przejścia pomiędzy stanami) – poniżej opiszę na przykładzie Błędu
  • każdy typ posiada swoje parametry. Dla buga zdefiniujemy więc np. priorytet, a dla zadania czas jego trwania
  • aż wreszcie – możemy rozszerzać definicję procesu, tworząc własne typy work itemów(postaram się poświęcić temu osobny wpis)

Definicja dla programisty :)

To tak naprawdę mała dygresja, ale może komuś będzie łatwiej przyswoić temat Work Itemów. Jeśli ktoś już czuje sie ok z work itemami i nie robi dużych oczu przy tej nazwie, może śmiało ten akapit pominąć :-)

Możnaby powiedzieć, że Work Item to abstrakcyjna klasa, z której dziedziczą takie klasy jak: Bug, Task, Risk etc. Nie możemy stworzyć instancji Work itema – tworzymy instancje “klas potomnych”. Mamy jednak pewien zestaw cech i funkcjonalności wspólnych, które są dziedziczone z tej “abstrakcyjnej klasy”.

Bug – opis

Spójrzmy sobie teraz bliżej na jeden z work itemów, czyli bug.

Przede wszystkim może znaleźć się w następujących stanach:

  • Active. Np. został właśnie założony przez testera.
  • Resolved. Np. rozwiązany przez developera.
  • Closed. Np. przetestowany ponownie, zweryfikowany przez testera.

 

 

Przy przejściach widnieje powód dla którego następuje zmiana stanu. Zgodnie z podstawowym przepływem, programista naprawia błąd i przestawia go w stan “Resolved” z uzasadnieniem “Fixed”. Tester weryfikuje i jeśli jednak nadal jest kiepsko przestawia w stan “Active”(np. z uzasadnieniem “Wrong Fix”), a jeśli błąd faktycznie został wyeliminowany – bug wędruje do stanu “Closed”. Może się jednak zdarzyć, że błąd wystąpi kiedyś ponownie – stąd możliwe przejście z powrotem do stanu “Active”.

 

W następnym odcinku…

Esmeralda dowie się, że jednak mieszka w Ekwadorze. Poza tym odkryje, co ciekawego pojawiło się w TFS 2010, jeśli chodzi o Work itemy :-) Stay tuned!



Czym dokładnie jest Visual Studio Team System?

29
cze/09
1

VSTSNazewnictwo związane z Visual Studio(i systemami związanymi) postanowiło się trochę zmieniać wraz z wypuszczaniem kolejnych wersji, co wprowadzało lekki chaos. Sam miałem problemy ze zrozumieniem co dokładnie kryje się pod nazwami takimi jak Visual Studio Team System, Visual Studio Team Suite, Team Foundation Server, jakie są między nimi różnice i jakich funkcjonalności dostarczają poszczególne edycje Visual Studio… Z moich rozmów ze znajomymi wynika, że nie tylko ja miałem ten problem.

Odnoszę wrażenie(bo pewności chyba jednak nie można mieć :) ), że udało mi się zrozumieć i co więcej, poniżej postaram się to opisać ;)

Różne wersje Visual Studio

Zaczniemy od omówienia jednego ze sztandarowych produktów, czyli samego IDE. W edycji Visual Studio 2003(wersjonowanej dla ułatwienia ;) również jako “Visual Studio .NET”) mieliśmy do czynienia z 3 wersjami: Professional, Enterprise Developer oraz Enterprise Architect. Był jeszcze wyróżniony Academic, ale przynajmniej wg tego zestawienia nie różnił się funkcjonalnie od Professional – przypuszczam, że jedyna różnica polegała na niekomercyjnym charakterze wykorzystania tej wersji(czyli nie można było pisać oprogramowania na sprzedaż).

Dwa lata później pojawia się Visual Studio 2005, razem z Team Foundation Serverem 2005(do którego zaraz wrócimy). Mamy tu np. edycje Standard, Professional, Express(mocno okrojona, ale pozwalająca na pisanie komercyjnych aplikacji). Co jest jednak ciekawe: wg witryny MS istnieje między innymi wersja Visual Studio Team System. Specjalnie zalogowałem się do MSDN, żeby sprawdzić – nie ma tam takiej pozycji :-)) Można pobrać za to Visual Studio 2005 Team Suite(najbogatsza, z punktu widzenia funkcjonalności “team”). Ale zwracają uwagę takie pozycje jak “Visual Studio 2005 Team Edition for Database Professionals”, czy też “Visual Studio 2005 Team Edition for Software Architects”. No to jak, w końcu są, czy nie są? :) Jesteśmy już bliscy rozwiązania zagadki. Na szczęście Microsoft przygotował obrazek, który “mówi więcej niż 1000 słów”:

 

VSTS_small

Struktura Visual Studio Team System

 

Reprezentuje on właśnie całe Visual Studio Team System. Na co warto zwrócić przede wszystkim uwagę: Cały produkt składa się z części serwerowej oraz klienckiej.
Centralnym punktem jest tu Team Foundation Server, stanowiący warstwę serwerową(jak widać na powyższej ilustracji, TFS zapewnia m.in. kontrolę wersji, raportowanie, buildy, ale również zarządzanie projektem, czy też śledzenie “jednostek roboczych”, czyli work itemów – a wszystko to w oparciu o konkretną metodykę wytwarzania oprogramowania).

Jeśli chodzi o część kliencką, mamy dostarczone różne “końcówki”, czyli aplikacje pozwalające na korzystanie z serwera. Najważniejsza to naturalnie seria produktów Visual Studio, czyli narzędzie codziennej pracy programistów. Dla różnych ról w projekcie zostały przygotowane dedykowane wydania, tj: Architecture/Development/Database/Test Edition. Istnieje również wydanie dostarczające wszystkich funkcjonalności z wymienionych 4 wersji: Visual Studio Team Suite.
Co ważne, nie zrezygnowano z wersji Standard oraz Professional – sama wersja Pro bardzo dobrze współpracuje z TFSem :) Nie wiem za to jak Standard.

VSTS dostarcza jednak również możliwości współpracy z Team Foundation Serverem za pośrednictwem Projecta i Excela(np. do zarządzania zadaniami, a mówiąc szerzej – do zarządzania Work Itemami, ale to temat na osobny wpis). Dodatkowo od wersji 2008 do rozwiązania została włączona aplikacja webowa(Team System Web Access), pozwalająca również na mieszanie w projektach ;)

Co więcej, Team System dostarcza całkiem bogatego API, a już sam Team Foundation Server wystawia kilka Web Service’ów, dzięki czemu możemy sobie napisać własną aplikację, współpracującą z serwerem.

 

Visual Studio Team System 2008 kontynuuje już powyższą filozofię, nie dzieje się tu więc nic specjalnego, poza wspomnianym Web Accessem, który został włączony jako integralna część Team Systemu – wcześniej trzeba było doinstalować go niezależnie.

A co z edycja 2010?

Jeśli chodzi o VSTS 2010, to na chwilę obecną, do ściągnięcia są wersje beta wydań Team Suite oraz Professional. Czytałem jednak w sieci o edycjach Development oraz Architecture Edition, więc zakładam, że linia produktów zostanie co najwyżej rozszerzona, ale nie zreorganizowana(i bardzo dobrze!) :-)

Podsumowanie

Mam nadzieję, że udało mi się troszkę rozwikłać co jest czym, jeśli chodzi o Visual Studio Team System. Na koniec ściągawka, w pigułce:

  • Visual Studio Team System – całe rozwiązanie, składające się zarówno z części serwerowej, jak również klienckiej. Zawiera w sobie wszystko co zostanie wymienione poniżej :)
  • Team Foundation Server – część serwerowa Team Systemu.
  • Visual Studio Team Suite(oraz inne edycje, dedykowane dla konkretnych ról projektowych) – część kliencka Team Systemu
  • Inne elementy takie jak Web Access – inne metody współpracy z TFS


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

20
cze/09
0

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)…



Instalujemy TFS 2010 Beta 1

13
cze/09
0

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! :-)