Zeyomir's Blog Bo piękniej jest wiedzieć coś o wszystkim…

Wprowadzenie do RedMine

Żaden projekt większy od prostego kalkulatora nie powinien być pisany bez użycia issue/bug trackera. Tak się składa, że jeden z lepszych systemów do prowadzenia projektów napisany jest w railsach i nazywa się RedMine :).

Konfiguracja RedMine

Po instalacji i zmianie hasła admina wypadałoby przystosować system do siebie. Właściwie wszystko jest wstępnie dobrze skonfigurowane, jest jednak parę rzeczy nad którymi warto się zastanowić:

• Administracja -> Role i uprawnienia- możemy tu dodać nowe role (jak grafik, tester etc) oraz ustawić co osoba z daną rolą może robić w systemie
• Administracja -> Dowolne pola- możemy tu dodać własne pola do wypełnienia przy konkretnych czynnościach, np dodanie obowiązkowego pola 'Telefon' do profilu użytkownika
• Administracja -> Wyliczenia- zmiana wartości dla różnych listBoxów
• Administracja -> Ustawienia- a tam:
  • Identyfikacja- jak długo zostajemy zalogowani oraz w jaki sposób aktywowane są nowe konta
  • Projekty- domyślnie włączane moduły oraz czy nowe projekty mają być publiczne
  • Powiadomienia email- które zdarzenia będą wyzwalać wysyłanie informacji do wszystkich członków zespołu
  • Repozytoria- jakie słowa będą automatycznie wiązać commity z zagadnieniami i zmieniać status tych zagadnień

Oprócz tego można spojrzeć na typy i statusy zagadnień, oraz sprawdzić przepływ.

Ustawienia projektu

Po stworzeniu nowego projektu przechodzimy do jego ustawień. W zakładce moduły ustawiamy jakie moduły mają być aktywne w tym konkretnym projekcie, przy czym należy pamiętać, że niektóre pozycje/moduły pojawiają się w górnym menu dopiero gdy jako administrator je utworzymy. Jest tak z forum (które pojawi się w menu dopiero gdy jakieś dodamy w ustawieniach) oraz z mapą (która pojawi się dopiero gdy w ustawieniach dodamy jakąś wersję). Najważniejszą jednak rzeczą jest podpięcie repozytorium. O ile podpięcie np svn to nie problem- podajemy adres repozytorium i już, o tyle z systemami rozproszonymi (a przynajmniej z gitem) jest trochę inaczej. Musimy podać LOKALNY adres do repozytorium- czyli coś w stylu /home/user/git/project/.git. Oznacza to, że repo musi znajdować się na tym samym serwerze co RedMine. Pół biedy jeśli mamy możliwość hostowania gita na tym samym serwerze- wtedy po prostu zakładamy tam główne repozytorium i z głowy- wszyscy tam commitują. Gorzej jeżeli z jakichś powodów repozytorium musi być hostowane gdzieś indziej- wtedy musimy je sklonować do siebie na serwer i... no właśnie, fajnie by było gdyby zawsze miało najświeższe commity... Rozwiązań tego problemu jest kilka, ja podam najprostsze ale jednocześnie chyba najsłabsze- stworzenie zadanie w crontab które robi git pull co np 5 minut. Po ciekawsze, mądrzejsze i wydajniejsze rozwiązania odsyłam do googli ;). Aha- jeżeli coś nie będzie działać przy dodawaniu repozytorium- upewnijcie się (np przez ftp), że wewnętrzne pliki gita znajdują się w katalogu projekt/.git a nie bezpośrednio w katalogu projekt ;). U mnie tak właśnie było i 'chwilkę' mi zajęło zanim doszedłem dlaczego to to nie chce działać 😛 oczywiście wystarczy wtedy podać ścieżkę do katalogu projekt.

Z poziomu szarego użytkownika

Po przeprawie z całą konfiguracją i ustawieniami, grzechem byłoby z tego nie korzystać ;). RedMine jest dość rozbudowany i łatwo się w nim na początku zgubić. Najłatwiej będzie to wszystko opisać przedstawiając podstawowy scenariusz użytkowania:

Posiadamy aktywne konto i zostaliśmy dodani do jakiegoś projektu jako programista. Klikamy w 'Moja strona' by sprawdzić czy ktoś nie przydzielił nam jakiegoś zadania. Na razie cisza. Sprawdźmy więc czy są jakieś nieprzydzielone zadania do wzięcia- na stronie projektu klikamy w 'zagadnienia'. Jest tego tyle, że nie wiadomo za co się wziąć, w dodatku prawie wszystkie z wysokim priorytetem... normalka ;). Sprawdźmy więc które zadania są potrzebne do aktualnie tworzonej wersji aplikacji- klikamy w 'mapa'. Okazuje się, że zostało tylko jedno wolne- zadanie nr 23.

Otwieramy je, klikamy 'uaktualnij' i w polu 'przydzielony do' wskazujemy swojego użytkownika. Pracujemy nad zadaniem przez półtorej godzinki i napisaliśmy jedną z funkcjonalności wchodzących w skład zadania. Commitujemy więc nasze zmiany do głównego repozytorium, w tytule opisu commita podając 'refs 23' dzięki czemu system sam połączy konkretnego commita z zadaniem którego dotyczył. Na stronie z zadaniem klikamy log czasu i podajemy, że przez tyle a tyle czasu (czas podajemy w godzinach więc teoretycznie powinniśmy napisać 1.5, ale możemy też napisać 1h30m- system i tak zrozumie o co nam chodziło) napisaliśmy to a to. Pracujemy dalej i ostatecznie udaje nam się ukończyć zadanie. Commitujemy, w tytule wpisując 'closes 23' dzięki czemu system nie tylko powiąże commit z zadaniem, ale sam przestawi % wykonania na '100%' i status na 'rozwiązano' (w zależności od ustawień). Ponownie dokumentujemy czas spędzony nad zadaniem używając 'logu czasu'.

Bawimy się chwilę aplikacją i odkrywamy błąd w funkcjonalności którą implementował nasz kolega. Sprawdzamy szybko czy błąd ten został już zgłoszony (Zagadnienia, dodaj filtr 'typ', równa się 'błąd')... nie ma. Klikamy więc 'Nowe zagadnienie', ustawiamy typ na błąd, wpisujemy o co chodzi, w jakich okolicznościach pojawia się błąd i dlaczego wg nas jest to błąd (to bardzo ważne przy zgłaszaniu błędów, ale o tym kiedy indziej). Przydzielamy zadanie naszemu koledze, ponieważ on będzie najlepiej znał kod odpowiedzialny za tę funkcjonalność. Wersję docelową ustawiamy na tą nad którą aktualnie pracuje zespół. Możemy jeszcze dorzucić screen przedstawiający co powoduje błąd, ustawić priorytet, szacowany czas wykonania i termin ukończenia zadania. Po utworzeniu możemy jeszcze odszukać zadanie w którym implementowana była funkcjonalność w której znaleźliśmy błąd i dodać je jako zagadnienie powiązane.

By zobaczyć czym należałoby się teraz zająć, klikamy w kalendarz i szukamy zadań, które powinny być niedługo ukończone. Bierzemy jedno i stwierdzamy, że jest za duże i można je podzielić na kilka mniejszych. Dodajemy więc nowe subtaski. Ma to tę zaletę, że system sam będzie wyliczał % ukończenia zadania głównego w miarę jak będziemy pracować nad jego subtaskami. Niestety pomimo tego, że RedMine jest świetny, to nie napisze za nas kodu więc... piszemy ;). Jeżeli jesteśmy PMem lub po prostu z nudów chcemy sprawdzić ile kto pracował, na stronie projektu przechodzimy do raportu.

Oprócz tego, możemy dorzucić do dokumentów np specyfikację tego co napisaliśmy, w wiki powinna się znaleźć instrukcja instalacji i konfiguracji środowiska developerskiego (np coś takiego powinno od biedy wystarczyć, ale musi mówić wprost z jakiej wersji korzystamy (+link) i być utrzymane w stylu 'kliknij to, potem to', bez zbędnego rozwodzenia się dlaczego ;)) oraz zasady pracy/krótki opis metodologii. Forum jak to forum- służy do tego do czego będziemy chcieli, żeby służyło. Najczęściej jest to jednak miejsce do zgłaszania pomysłów/problemów z zadaniami i dyskusji o nich. W repozytorium nie ma zasadniczo nic czego nie moglibyśmy sprawdzić używając normalnego klienta, no ale czasem łatwiej sobie coś wyklikać. Wykres Gantta jest przydatny raczej tylko managerowi projektu. Możemy na nim sprawdzić 'jak idzie praca'- od kiedy do kiedy trwają poszczególne zadania i czy nie mamy opóźnień (np jutro kończy się zadanie które trwało tydzień, a my mamy zrobione 10%, albo jakieś zadanie powinno być skończone już wczoraj). Niestety wszystko wskazuje na to, że generacja wykresu nie jest wolna od błędów- np grupowanie zadań z ich subtaskami nie działa w ogóle, a właściwie to działa tak, że wprowadza w błąd.

Jako wisienka na torcie mamy jeszcze mnóstwo pluginów :). Niestety część z nich nie jest już rozwijana i nie jest kompatybilna z nową wersją RedMine, a część zawiera po prostu masę błędów.