Kontynuując serię postów filozoficznych z początku konkursu dzisiaj będzie o systemie kontroli wersji.
Dlaczego system kontroli wersji jest nam potrzebny?
- Dzięki temu możemy w każdym momencie wrócić do wcześniejszej wersji naszego projektu. To też wymaga od nas abyśmy regularnie zwracali (wykonywali commit, checkin w zależności od systemu kontroli wersji) kod.
- W razie awarii komputera, mamy backup naszych źródeł czyli największego aktywa w przypadku firm/osób zajmujących się tworzeniem oprogramowania
- ….i najważniejsze. Możemy pracować w zespole, w którym każda osoba pracuje nad inną częścią programu. System kontroli wersji ułatwi nam utrzymanie źródeł w całości i prawidłowe łączenie zmian wszystkich osób z głównym projektem
- …oczywiście są dodatkowe plusy, takie jak możliwość rozproszenia programistów po całym świecie
- Zwiększenie jakości kodu
- Zwiększona kontrola nad poczynaniami pracowników etc
Można by wymieniać dalej, ale uważam, że trzy pierwsze powody są najważniejsze dla pytania po co nam system kontroli wersji.
Na potrzeby konkursu skorzystałem z CodePlex-a który daje możliwość korzystania z TFS-a. Pełny Team Foundation Server jest potężnym narzędziem do zarówno kontroli wersji jak i zarządzania projektem, zarządzania błędami, testami, buildami, projektem architektury, bazy etc. Narzędzie to, to wprost niesamowity kombajn – niestety kosztuje również jak nowy kombajn zbożowy. CodePlex daje nam namiastke tego. Wybierając dla naszego projektu Visual Studio Team Explorer dostajemy namiastkę płatnej wersji TFS-a. To czego w tym momencie potrzebujemy to zainstalowanie Team Explorera – czyli klienta TFS-a który jest do pobrania ze stron CodePlex. Paczka waży około 300MB i spotkałem się już z głosami że tyle aby tylko dostać się do źródeł to przesada ale Team Explorer to nie tylko dostęp do źródeł więc nie ma sensu tutaj w ogóle podejmować takich dyskusji.
Zainstalowałem Team Exporer – co dalej?
Po instalacji w Visual Studio mamy dostęp do nowej zakładki – Team Explorer
Korzystając z CodePlex-a nie mamy tutaj zbyt wiele bo tylko Work Items oraz Source Control – do tej pory nie udało mi się wykorzystać Builds-a (a trzeba wspomnieć że korzystając z pełnego TFS-a tutaj możemy uruchamiać automatyczne buildy, które skompilują wersję, uruchomią testy jednostkowe oraz testy przygotowane przez testerów, mogą spakować wersję do zip-a i opublikować na serwerze a w wersji TFS2010 również uruchomić maszynę wirtualną, na niej zainstalować skompilowaną właśnie paczkę, przeprowadzić testy i przywrócić maszynę wirtualną do stanu sprzed testów).
To co oprócz przechowywania źródeł nas tutaj interesuje to owe Work Items:
Otwierając All Work Items mamy możliwość przeglądania wszystkiego co mamy do wykonania oraz tworzenia nowych Work Items-ów czyli nowych rzeczy do wykonania
To co tutaj możemy zrobić to przegląd istniejących zadań, możemy ich listę wyeksportować do Excel-a do dalszych analiz
Lub przesłać Outlookiem. W końcu sami możemy modyfikować zapytanie, za pomocą którego pobierane są wszystkie WorkItemy poprzez edycję zapytania (Query)
W gałęzi Team Queries znajdziemy dwa elementy All Work Items oraz My Work Items. To pierwsze to po prostu lista wszystkich rzeczy do zrobienia, drugie natomiast to rzeczy przypisane do mnie.
Jak zatem tworzyć WorkItemy?
Wybierając prawy klawisz na pozycji WorkItems możemy łatwo i szybko stworzyć nowy WorkItem.
Teraz co pozostaje to opisać typ, priorytet, komponent do którego będzie przypisany WorkItem, kto ma się tym zając (jeśli pracujemy w większym zespole), status i kiedy planowany release tej funkcjonalności. Oczywiście mamy miejsce na opis, komentarze oraz możemy załączać dodatkowe pliki jak na przykład projekty wyglądu czy dodatkowe specyfikacje.
A teraz najważniejsze…. Wszystko to co tutaj sobie gromadzimy, w przypadku CodePlex-a dostępne jest na stronie naszego projektu. U mnie rzeczy do zrobienia znajdują się tutaj
Dodatkowo można na stronie głosować na konkretne funkcjonalności ale to nie wiem jak działa ponieważ jeszcze nikt nie głosował 😉
Pozostaje mi jeszcze wspomnieć o jednym. WorkItemy warto zapisywać nie tylko dlatego że możemy prowadzić listę rzeczy do wykonania w naszym projekcie, ale również możemy workItemy wiązać z konkretnym kodem.
W momencie zwrotu kodu do repozytorium (w TFSie Check In) możemy z kodem związać WorkItem który wykonaliśmy.
Nie wiem jakie możliwości mają inne online-owe narzędzia kontroli wersji dlatego nie porównuję ich. Jeśli ktoś z was ma chwilę na opisanie swojego rozwiązania, chętnie poczytam i poszukam innego narzędzia o podobnych możliwościach.
