Galka.MountLab.net
Poligon doświadczalny Damiana Gałki.

Programowanie

Zarządzanie wersjami i wydaniami. Teoria i praktyka

Wielu z nas pisząc aplikacje używa własnych sposobów nadawania numerów wersji dla aplikacji czy dokumentów. Większość jest podobna do siebie lecz istnieje prawdopdobieństwo ich odmiennej interpretacji przez różne osoby. W związku z tym postaram się opisać jeden z najpopularniejszych spsobów wersjonowania aplikacji wraz z odpowiednim wstępem teoretycznym.

1. Teoria

Zarządzanie wersjami i wydaniami to procesy identyfikowania i śledzenia różnych wersji i wydań danego systemu, w poszczególnych etapach jego tworzenia i rozwoju. Za dokonywanie zmian przy dużych projektach w firmach odpowiedzialni są tzw. menedżerowie wersji. To oni obmyślają procedury zapewniające w razie potrzeby możliwość pobrania różnych wersji systemu i zapobiegają przypadkowym zmianom.

Pojawiły się tutaj pojęcia “wersja systemu” oraz “wydanie systemu”, które należy sprecyzować. Ian Sommerville w swojej książce “Inżynieria oprogramowania” definiuje je następująco:
Wersja systemu to egzemplarz systemu, który w pewien sposób różni się od innych egzemplarzy. Nowe wersje systemu mogą mieć inną funkcjonalność, efektywność lub mogą powstać w wyniku naprawy usterek. Niektóre wersje mogą być funkcjonalnie równoważne, ale za to zaprojektowane z myślą o innej konfiguracji sprzętu lub oprogramowania. Jeśli między wersjami występują jedynie niewielkie zmiany, to jedna z nich nosi czasem nazwę wariantu tej drugiej.
Wydanie systemu to wersja przekazywana klientom. Każde wydanie systemu powinno zawierać nową funkcjonalność albo być przeznaczone na inną platformę sprzętową. Zawsze jest więcej wersji systemu niż jego wydań.[1]

Duże systemy oprogramowania składają się z setek komponentów programowych, z których każdy może istnieć w wielu różnych wersjach. Opracowując procedury zarządzania wersjami należy zdefiniować jednoznaczny sposób identyfikacji każdej wersji komponentu. Ian Somerville zwraca uwagę na trzy metody, których można użyć do identyfikacji komponentów.

  1. Numerowanie wersji. Komponent otrzymuje jawny i unikatowy numer wersji. Jest to najczęściej spotykany schemat identyfikacji i jemu poświęcę najwięcej uwagi.
  2. Identyfikacja atrybutowa. Każdy komponent ma nazwę (która w różnych wersjach nie jest unikatowa) i zbiór atrybutów, które są inne w każdej wersji komponentu. Komponenty identyfikuje się więc za pomocą kombinacji nazwy i zbioru atrybutów.
  3. Identyfikacja zmianowa. Każdy system nosi nazwę tak jak w wypadku identyfikacji atrybutowej, ale jest również kojarzony z co najmniej jednym żądaniem zmiany. Wersje systemu identyfikuje się przez związanie nazwy ze zmianami zaimplementowanymi w komponencie.[2]
W najprosztrzym schemacie numerowania wersji nazwa komponentu, systemu, aplikacji lub dokumentu rozszerzana jest o numer wersji, na przykład:
Solaris 2.4
Pierwsza wersja może mieć numer 1.0, a kolejne 1.1, 1.2, itd. W pewnym momencie może powstać nowe wydanie (wydanie 2.0) i numerowanie zaczyna się od wersji 2.1, 2.2, itd. Schemat jest liniowy jeśli założymy, że wersje systemu powstają po kolei. Inne podejście przedstawiono na rysunku poniżej:

Struktura wyprowadzenia wersji
Rys. 1. Struktura wyprowadzenia wersji.[3]

Na tym diagramie strzałki wychodzą od wersji źródłowej do nowej wersji utworzonej na podstawie tego źródła. Wyprowadzenie wersji nie musi być liniowe, co widać na przykładzie wersji 2.2, która jest tworzona na podstawie wersji 1.2, a nie 2.1. Schemat ten jest prosty, ale wymaga bardzo starannego zarządzania informacjami na temat zmian i różnic w poszczególnych wersjach. Pamiętajmy więc, iż decydując o kolejnym wydaniu systemu poza samym kodem (z odpowiednimi kometarzami) powinniśmy również dostarczyć:
Pamiętajmy również o tym, iż część użytkowników mogła nie uaktualnić pierwszego wydania systemu w momencie publikacji wydania drugiego i gdy chcemy przejsć do wydania trzeciego powinniśmy uwzględnić potrzebę aktualizacji bezpośrednio z wydania pierwszego do trzeciego.

2. Praktyka w MountLab Group

Po streszczeniu części teoretycznej związanej z zarządzaniem wersjami i wydaniami przyszedł czas na praktykę. Przedstawiony poniżej schematu wersjonowania jest propozycją dla osób pracujących w ramach MountLab Group. System, jego komponenty, skrypty czy dokumenty proponuję oznaczać w następujący sposób:
<nazwa komponentu> <numer wersji / wydania> - <kategoria wersji>

2.1 Nazwa komponentu jest ciągiem unikalnych znaków nadanych przez twórcę. Dalszą analizę tego elementu pominę uważając, iż jest to zrozumiałe i logiczne.

2.2 Numer wersji / wydania to nic innego jak ciąg cyfr i kropek określający wersję. Numer wersji czy wydania posiada swój własny specyficzny “pod schemat”, który wygląda następująco:
<major>.<minor>.<path/build>
Gdzie major, minor i path/build to znaki liczbowe. Ostatni element (path/build) może być pominięty, jeżeli wynosi 0 (zero).
major
Major charakteryzuje nam wersje, która w porównaniu do poprzedniej posiada znaczące zmiany, nieograniczające się tylko do kosmetyki, ale do ważnych aspektów działania aplikacji. Może to być np. nowy sposób komunikacji się aplikacji z klientem, nowy rodzaj wymiany danych czy zupełnie inny sposób działania całego systemu.
minor
Minor określa wprowadzenie nowych elementów do aplikacji nie wpływających w znaczącym stopniu na zmiany w strukturze całej aplikacji. Może to być np. dodanie nowych przycisków czy innych elementów, które na drodze np. kontaktu z klientem doprowadziły do zmian w celu podniesienia funkcjonalności aplikacji.
path/build
Path/build jest numerem określającym wprowadzenie poprawki naprawiającej wykryty błąd/błędy albo numer kompilacji programu (inkrementowany przez kompilator).

2.3 Kategoria to dodatkowy atrybut nadawany wersjom, które mają specyficzne przeznaczenie. Tutaj przewiduję następujące atrybuty:
Develope (Skrót: dev lub d)
Kategoria komponentów, które są w fazie rozwojowej. Dostępne dla określonej grupy ludzi (przeważnie developerów lub zaufanych członków zespołu).
Alpha (Skrót: alpha lub a)
Kategoria komponentów, która przeszła “głosowanie” - została zaakceptowana przez grupę developerów do dalszych testów przez nich samych.
Beta (Skrót: beta lub b)
Kategoria przeznaczona dla szerszej grupy testerów - członków pracujących nad projektem zajmujących się głównie testowaniem aplikacji.
Relase Candidate / Relase (Skróty: rc lub r)
Kategoria komponentów przeznaczona dla wszystkich zainteresowanych osób. Posiadająca najmniej błędów - w porównaniu do powyższych kategorii. Jest to częściowo skończony projekt, z większością możliwości, jakie będzie posiadał finalny produkt. Przeważnie aplikacja taka jest po to, aby poprawić elementy, które użytkownik końcowy uzna za źle rozwiązane (np. nawigacja w programie, kolory itp. itd.) oraz błędy, które wcześniej nie zostały wykryte.
Final (Skrót final lub f)
Ostateczne wydanie trafiające do klienta. Przeważnie nie dodaje się tej kategorii do wersji i jest ona “umowna”.

Trzeba zaznaczyć, że do kategorii można dodać także dodatkowy numer np. RC 1, RC 2. Określający kolejny “pod etap” w wersjonowaniu komponentu. Im wyższy numer tym “szybciej” do następnej kategorii (nie ma maksymalnej granicy w nadawaniu dodatkowych numerów, jednak nie powinny one przekraczać cyfry 5).

3. Przykłady

File Manager 1.0
Pierwsza finalna wersja

File Manager 0.1-dev
Aplikacja w fazie rozwojowej, która nie posiada jeszcze wszystkich elementów “pełnej” wersji

File Manager 2.2.34
Finalna aplikacja zawierająca pewne poprawki w stosunku do wersji 2.0 oraz załatane dziury

File Manager 1.0-RC
Pierwsza wersja aplikacji przeznaczona do testowania przez osoby z zewnątrz

4. Przypisy

1. Ian Sommerville, “Inżynieria oprogramowania”, Wydawnictwa Naukowo-Techniczne, Warszawa 2003, str. 650
2. tamże str. 651
3. tamże str. 651

PS.

Artykuł napisany na podstawie:
1. Ian Sommerville, “Inżynieria oprogramowania”, Wydawnictwa Naukowo-Techniczne, Warszawa 2003.
2. Michał “Seth” Gołębiowski, “Wersjonowanie aplikacji”, wortal php.pl


Na górę strony

wersja 1.0 2005.07.16.