Kontrola wersji

Z Encyklopedia Zarządzania
Wersja z dnia 09:21, 19 maj 2020 autorstwa Sw (dyskusja | edycje) (Infobox update)
(różn.) ← poprzednia wersja | przejdź do aktualnej wersji (różn.) | następna wersja → (różn.)
Kontrola wersji
Polecane artykuły


Kontrola wersji (ang. Version Control System, Revision Control System) – to system narzędzi pomocnych w zarządzaniu kodem źródłowym. Oprogramowanie śledzi każdą modyfikację kodu źródłowego i odnotowuje rezultaty w specjalnej bazie danych. Kontrola wersji umożliwia dostęp do starszych wersji projektu, jeśli więc zostanie popełniony jakikolwiek błąd, programista może szybko się cofnąć i porównać poprzednie wersje kodu. W ten sposób można usunąć usterkę. To również rodzaj zabezpieczenia przed następstwami awarii komputerów lub utratą danych (Ernst M. 2012, s. 5).

Obecnie systemy kontroli wersji są niezbędnymi narzędziami w świecie inżynierii oprogramowania. W zasadzie każdy projekt, niezależnie od stopnia skomplikowania i nakładu pracy niezbędnego do jego wykonania, używa kontroli wersji. Kontrola wersji umożliwia jednoczesną pracę wielu osób przy jednym projekcie. Każda osoba edytuje swoją własną kopię pliku i wybiera kiedy podzielić się tymi zmianami zresztą zespołu. Tak, że chwilowe lub częściowe edycje dokonane przez jedną z osób nie interferują z pracą wykonywaną przez resztę członków zespołu. W szczególnych przypadkach, kiedy dwie osoby edytują tą samą linię kodu, kontrola wersji wymaga interwencji ze strony użytkownika, który podejmuje decyzję co robić dalej (Chancon S., Straub B. 2014, s. 27).

Programiści pracujący w zespołach projektowych stale piszą nowy i zmieniają istniejący kod źródłowy. Kod dla projektu, aplikacji lub komponentu oprogramowania jest zwykle organizowany w strukturze folderów. Każdy programista może edytować dowolne pliki (Wheeler D. 2012, s. 17).

Kontrola wersji pomaga zespołom rozwiązywać tego rodzaju problemy, śledzić każdą indywidualną zmianę przez każdego użytkownika i ułatwiać ich rozwiązanie. Zmiany dokonane w jednej części oprogramowania mogą być niezgodne z tymi, które zostały wykonane przez innego dewelopera pracującego w tym samym czasie. Ten problem powinien zostać wykryty i rozwiązany w sposób uporządkowany bez blokowania pracy reszty zespołu. Ponadto, we wszystkich programach, każda zmiana może sama w sobie wprowadzić nowe błędy, a nowe oprogramowanie nie może być zaufane do czasu przetestowania. Więc testowanie i rozwijanie działają razem, dopóki nowa wersja nie będzie gotowa.

Popularnym systemem używanym do kontroli wersji jest narzędzie o nazwie Git dostępne na serwisie hostingowym GitHub.com (Gousios G., Spinellis D. 2017, s. 501).

Repozytoria i kopie robocze

Kontrola wersji używa repozytorium (bazy zmian) i kopii roboczej, w której programista wykonuje swoją pracę. Kopia robocza pracownika umożliwia mu dowolną modyfikację pliku, nie wpływając na pliki używane przez współpracowników. Jeśli są oni zadowoleni ze zmian, pracownik wprowadza zmiany do repozytorium (Sink E. 2011, s. 141).

W najprostszym przypadku baza danych zawiera historię liniową: każda zmiana następuje po poprzedniej (Rys. 1).

Rys. 1 Schemat bazy danych zawierającej historię liniową

W kolejnym wariancie inni użytkownicy dokonują jedocześnie edycji (rozgałęzienia). W takim przypadku historia wersji dzieli się, a następnie łączy (Rys. 2).

Rys. 2 Schemat bazy danych zawierającej historię rozgałęzioną

Systemy kontroli wersji

  • Lokalne systemy kontroli wersji

Składają się z prostej bazy danych, na których przechowywane są wszystkie zmiany dokonane na śledzonych plikach. Programy te działają zapisując, w specjalnym formacie na dysku, dane różnicowe (zawierające jedynie różnice pomiędzy plikami) z każdej dokonanej modyfikacji. Używając tych danych program jest w stanie przywołać stan pliku z dowolnego momentu (Rys. 3).

Rys. 3 Schemat lokalnego systemu kontroli wersji
  • Scentralizowane systemy kontroli wersji

Systemy takie składają się z serwera, na którym znajdują się wszystkie pliki poddane kontroli wersji, oraz z klientów, którzy mogą się z nimi łączyć by uzyskać dostęp do aktualnych wersji plików. System ten posiada niewątpliwie tą zaletę, że każdy programista może się zorientować co robią jego partnerzy z zespołu. Scentralizowane systemy kontroli wersji są ponadto łatwiejsze w zarządzaniu niż lokalne bazy danych u każdego z klientów. Najistotniejszym problemem przy zastosowaniu tego rozwiązania jest fakt, że w wyniku awarii centralnego serwera tracimy możliwość dostępu do plików (Rys. 4).

Rys. 4 Schemat scentralizowanego systemu kontroli wersji
  • Rozproszone systemy kontroli wersji

W tych systemach klienci dostają oprócz dostępu do najnowszych wersji plików całe repozytorium. W porównaniu do scentralizowanych systemów kontroli wersji, gdy serwer ulegnie awarii, repozytorium każdego klienta może zostać skopiowane na ten serwer w celu przywrócenia go do pracy (Rys. 5).

Rys. 5 Schemat rozproszonego systemu kontroli wersji

Zalety korzystania z systemów kontroli

  • Pełna długoterminowa historia zmian każdego pliku

Oznacza to rejestrowanie wszystkich zmian dokonywanych przez wiele osób na przestrzeni lat. Zmiany obejmują tworzenie i usuwanie plików oraz zmiany ich zawartości. Historia powinna również zawierać autora, datę i pisemne notatki dotyczące celu każdej zmiany. Pełna historia umożliwia powrót do poprzednich wersji, aby pomóc w analizie głównych przyczyn błędów i jest niezbędna w przypadku rozwiązywania problemów w starszych wersjach oprogramowania (Sink E. 2011, s. 52-53).

  • Podział i łączenie

Utworzenie rozgałęzień umożliwia niezależne od siebie nawiązywanie wielu strumieni pracy, zapewniając jednocześnie możliwość scalenia tej pracy z powrotem. Pozwala to programistom na sprawdzenie, czy zmiany w opracowywanych przez nich wersjach nie są sprzeczne (Sink E. 2011, s. 52).

  • Możliwość śledzenia

Można śledzić każdą zmianę wprowadzoną do oprogramowania i połączyć ją z oprogramowaniem do zarządzania projektami i oprogramowaniem do śledzenia błędów. Następnie można opisać każdą zmianę za pomocą komunikatu opisującego cel i zamiar zmiany. Posiadając opisaną historię kodu na wyciągnięcie umożliwia się twórcom kodu prawidłowe i harmonijne zmiany, które są zgodne z zamierzonym długoterminowym projektem systemu. Może to być szczególnie ważne do skutecznego działania ze starszymi wersjami kodu i ma kluczowe znaczenie dla umożliwienia programistom szacowania przyszłych prac z dowolną dokładnością (Sink E. 2011, s. 54).

Bibliografia

  • Loeliger J. (2014). Kontrola wersji z systemem Git: narzędzia i techniki programistów, Helion, Gliwice
  • Sink E. (2011). Version control by example, Pyrenean Gold Press, Champaign, Illinois
  • Wheeler D. (2012). Software Inspection: An Industry Best Practice, John Wiley & Sons: IEEE Computer Society Press, Hoboken, New Jersey

Autor: Mateusz Stasiak