Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc

TFS a proces tworzenia oprogramowania

W świecie projektów .Netowych dość często spotykam się z sytuacją, gdzie intensywnie używane jest Visual Studio, natomiast rola TFS ogranicza się jedynie do kontroli wersji. Co prawda od czasu do czasu ktoś stworzy Taska lub Buga, w porywach nawet dołączy do niego związany kod, jednak nie ma to wiele wspólnego z ogólnie obowiązujacym procesem (inna sprawa czy w ogóle obowiązuje jakiś proces :)).
A jednak nazwa Team Foundation Server wskazuje na pewien zakres odpowiedzialności w pracy zepołu.
Skąd więc ta niechęć? Czyżby TFS nie był narzędziem prostym, łatwym i przyjemnym? A może brakuje mu czegoś, co uniemożliwia wdrożenie specyficznych dla projektu aspektów?
Chyba nie jest tak źle, skoro równocześnie istnieje tyle firm i zespołów niemal w pełni wykorzystujacych ofertę TFSa.
Może problem tkwi w niedokładnej eksploracji i braku świadomości o jego możliwościach. Postaram się pokazać zalążek tych możliwości oraz tego, co można zrobić mając gotowy projekt procesu.

A więc niech stanie sie proces...

Na potrzeby przykładu będę operować jedynie na TFSowych Taskach, ale proponowane rozwiązanie może być zastosowane dla dowolnego Work Itema włączając w to nowe typy zdefiniowane przez zespół.

Załóżmy, że chcemy zamodelować w TFSie następujący proces zmiany stanu zadań:

Oprócz tego zadanie powinno mieć dodatkowe pole oznaczające kod (mający ogromne znaczenie w naszym projekcie :)), dla pokazania łatwości zmiany kształtu i wyglądu zadania.

Dostosowanie do naszych potrzeb oznacza również dodatkowe ograniczenia:
- osoba która stworzyła zadanie nie może go aktywować,
- implementowanie zadania może byc przypisane jedynie do osoby z grupy Developers,
- wdrażanie zadania może być przypisanie jedynie do osoby z grupy Deployers, ale nie może to być ta sama osoba, która zaimplementowała zadanie,
- zamknąć zadanie może jedynie osoba która je stworzyła.

Wdrażanie zmian

Aby zmienić definicję Taska należy najpierw ściągnąć jego definicję z servera. Robimy to dzięki komendzie (Visual Studio Command Prompt):

witadmin exportwitd /collection:<ServerAddress> /p:<ProjectName> /n:Task /f:<DiskLocation>\<filename>.xml

Dzięki temu w miejscu <DiskLocation>\<filename>.xml powstanie plik z definicją, na której od tej pory będziemy pracować. Chcąc zmieniać definicję Taska można zaimportować na serwer nową definicję. Można również stworzyć swój własny typ przez wprowadzenie nowej nazwy w tagu:
<WORKITEMTYPE name="Special Task">

Import definicji na serwer odbywa sie przez użycie nastepujacej instrukcji:

witadmin importwitd /collection:<ServerAddress> /p:<ProjectName> /f:<DiskLocation>\<filename>.xml

Zmiana layoutu

Dodatkowe pole kodu w definicji Taska dodajemy przez wstawienie do <FIELDS> następującego wpisu:

<FIELD name="ProjectCode" refname="MyCompany.MyProcess.ProjectCode" type="String">
    <HELPTEXT>Describes the project code.</HELPTEXT>
</FIELD>


Widoczność i edytowalność pola uzmożliwia xml, wstawiony w wybranym przez nas miejscu w <FORM><Layout>:

<Control Type="FieldControl" FieldName="MyCompany.MyProcess.ProjectCode" Label="Project Code" LabelPosition="Left" />

Oczywiście możemy dodawać pola o różnych typach, edytowane w różnych kontrolkach. Podany przeze mnie przykład obejmuje sytuację najprostszą: string i textbox.

Efekt widać po imporcie definicji:



Modelowanie procesu

Aby w procesie zmian stanu zadania pojawiły się odpowiednie wartości, należy wprowadzić zmiany w tagach <WORKFLOW><STATES> i <WORKFLOW><TRANSITIONS>.

Definicje stanów (<WORKFLOW><STATES>):

        <STATE value="Unapproved">
        </
STATE>
        <
STATE  value="Active">
        </
STATE>
        <
STATE value="Implemented">
        </
STATE>
        <
STATE value="Deployed">
        </
STATE>
        <
STATE value="Closed">
        </
STATE>

Przejścia między stanami natomiast (<WORKFLOW><TRANSITIONS>):

        <TRANSITION from="Unapproved" to="Active">

Przedstawiany przeze mnie proces jest prosty i nie zawiera powrotów ani pętli, ale można to z powodzeniem zamodelować.

Przypisywanie osób i ograniczanie dostępu

A teraz najtrudniejsza część - ograniczenia dostępu:

(1) Osoba, która stworzyła zadanie nie może go aktywować.

Najpierw dodamy nowe pole, które będzie przechowywać informację o tym kto stworzył zadanie:

<FIELD name="PreparedBy" refname="MyCompany.MyProcess.PreparedBy" type="String">
        <HELPTEXT>Person that created the task.</HELPTEXT>
</FIELD>

Pole to jest wypełniane obecnym użytkownikiem w pierwszej tranzycji, czyli gdy zadanie jest tworzone:

<TRANSITION from="" to="Unapproved">
        ...  
    <FIELDS>
            <FIELD refname="MyCompany.MyProcess.PreparedBy">
              <COPY from="currentuser" />
            </FIELD>
            ...
    </FIELDS>
</
TRANSITION>

W tranzycji z "Unapproved" do "Active" do pola "ActivatedBy" wstawiamy ograniczenie:

<FIELD refname="Microsoft.VSTS.Common.ActivatedBy">
   <ALLOWEXISTINGVALUE />
   <COPY from="currentuser" />
   <NOTSAMEAS field="MyCompany.MyProcess.PreparedBy"/>
   <VALIDUSER />
   <REQUIRED />
</FIELD>


(2) Implementowanie zadania może byc przypisane jedynie do osoby z grupy Developers.

Po pierwsze prawo do dokonania tranzycji mają jedynie developerzy:
<TRANSITION from="Active" to="Implemented" for="[Project]\Developers">

Po drugie lista osób możliwych do przypisania powinna być róznież ograniczona:
          <FIELDS>
            <FIELD refname="System.AssignedTo">
              <ALLOWEDVALUES expanditems="true">
                <LISTITEM value="[Project]\Developers" />
              </ALLOWEDVALUES>

              <COPY from="currentuser" />
            </FIELD>
          </FIELDS>


Dodatkowo dodajemy do Taska pole, które przyda sie w nastepnym kroku:
        <FIELD refname="MyCompany.MyProcess.ImplementedBy">
              <COPY from="currentuser" />
        </FIELD>


(3) Wdrażanie zadania może być przypisanie jedynie do osoby z grupy Deployers, ale nie może to byc ta sama osoba która zaimplementowała zadanie.

Podobnie jak wcześniej ograniczamy dostęp w tranzycji:
<TRANSITION from="Implemented" to="Deployed" for="[Project]\Deployers">

Pola dla tranzycji wyglądają teraz następująco:
          <FIELDS>
            <FIELD refname="System.AssignedTo">
              <ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
                <LISTITEM value="[Project]\DeploymentAdministrators" />
              </ALLOWEDVALUES>
              <COPY from="currentuser" />
            </FIELD>
            <FIELD refname="MyCompany.MyProcess.DeployedBy">
              <COPY from="currentuser" />
              <NOTSAMEAS field="MyCompany.MyProcess.ImplementedBy"/>
            </FIELD>
          </FIELDS>


(4) Zamknąć zadanie może tylko osoba która je stworzyła.

Tutaj przy się pewna sztuczka ponieważ nie mamy do dyspozycji znacznika typu <SAMEAS>.
Definiujemy więc pole które jest oznaczone jako FROZEN:

<FIELD name="ClosedByValidation" refname="MyCompany.MyProcess.ClosedByValidation" type="String">
        <HELPTEXT>Person that closed the task.</HELPTEXT>
        <FROZEN/>
</FIELD>


A do wnetrza obydwu stanów: Unapproved i Closed wrzucamy nastepujacy zapis:
    <FIELDS>
            <FIELD refname="MyCompany.MyProcess.ClosedByValidation">
              <COPY from="currentuser" />
            </FIELD>
    </FIELDS>


Powoduje to sytuację, w której stworzenie zadania zapisaniem obecnego uzytkownika. Każda następna próba zapisu spowoduje błąd jeśli wartość nie będzie zgodna z juz istniejącą, co spowoduje bład:


To tylko kilka pomysłów... Mam nadzieję, że przydadzą się w modelowaniu waszych własnych procesów :)

Opublikowane 20 maja 2011 14:29 przez fusion
Filed under: ,

Komentarze:

20 maja 2011 20:52 by dotnetomaniak.pl

# Cold Fusion : TFS a proces tworzenia oprogramowania

Dziękujemy za publikację - Trackback z dotnetomaniak.pl

21 maja 2011 10:20 by Michał Chaniewski

# re: TFS a proces tworzenia oprogramowania

Problem z TFS jest taki, że chyba trudno znaleźć bardziej niewygodne i nieintuicyjne w użyciu narzędzie. Szczerze powiedziawszy, po użyciu go w trzech różnych projektach i szczerych chęciach, by w pełni wykorzystać jego możliwości, poddaję się. Każda czynność wykonywna w koszmarnym GUI TFS-a trwa kilka razy dłużej niż powinna i jest naprawdę daleka od intuicyjności.

I owszem, są narzędzia które ułatwiają pracę z TFS-em - ale w dalszym ciągu to nie to.

Mając za konkurencję takie cuda jak np. Pivotal Tracker czy Kanbanery, panowie z Microsoftu muszą się sporo jeszcze postarać. I nawet pięknie działające powiązania systemu kontroli wersji z systemem zarządzania zadaniami nie wynagrodzą tego, że TFS w codziennym użyciu jest po prostu kłodą rzuconą pod nogi. Nigdy więcej....

21 maja 2011 17:35 by fusion

# re: TFS a proces tworzenia oprogramowania

Michał,

Niestety, dużo prawdy jest w tym co piszesz...

Trochę przegięłam z tym łatwym, prostym i przyjemnym narzędziem :)

23 maja 2011 09:04 by Szymon Pobiega

# re: TFS a proces tworzenia oprogramowania

Michale,

Niestety mam dla Ciebie złe wieści: w Infusion póki co TFS rządzi;) Ale mam nadzieję, że to się zmieni niedługo, bo lobby gitowe jest silne.

Basiu,

Dzięki za spisanie tego wszystkiego w jednym miejscu. Być może będę tego niedługo (niestety) potrzebował.

23 maja 2011 23:49 by tentod

# re: TFS a proces tworzenia oprogramowania

Niestety, TFS nadaje się tylko i wyłącznie kontroli wersji... Dziwne, bo od tak drogiego narzędzia możnaby spodziewać się więcej... Niestety, raportowanie godzin leży, znalezienie czegokolwiek - leży, filtrowanie, wyszukiwanie leży... Gdyby nie MOSS i fakt, ze wszystkie dokumenty są w jednym miejscu i można je wspólnie współtworzyć, pewnie już dawno zrezygnowalibyśmy z tego rozwiązania na rzecz choćby Hg...

Może w następnych wersjach będzie lepiej...

Pozdrawiam

Komentarze anonimowe wyłączone