1

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania

Autor: Łukasz Olek

Witam Państwa serdecznie na wykładzie poświęconym zarządzaniu
konfiguracją oprogramowania.

2

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (2)

Plan wykładów

Zasady skutecznego działania
Specyfikacja wymagań
Kontrola jakości artefaktów
Język UML, cz. I
Język UML, cz. II
Metody formalne
Wzorce projektowe

Zarządzanie konfiguracją

Wprowadzenie do testowania
Automatyzacja wykonywania testów
Programowanie Ekstremalne
Ewolucja oprogramowania i refaktoryzacja

Jest to ósmy wykład z cyklu.
Dowiedzieliśmy się już o takich zagadnieniach jak przygotowywanie
specyfikacji wymagań, projektowaniu w języku UML, poznaliśmy wzorce
projektowe… Obecny wykład pomoże zrozumieć metody zapanowania nad
tymi wszystkimi artefaktami i ich zmianami, jakie mają miejsce w projektach
informatycznych.

Zarządzanie konfiguracją oprogramowania to zestaw czynności
pozwalających kontrolować zmiany. Robione to jest poprzez identyfikację
elementów, które mogą się zmieniać, ustalenie relacji pomiędzy nimi,
określenie mechanizmów zarządzania wersjami.

Dla osób, które do tej pory pracowały jedynie w pojedynkę, takie rzeczy mogą
się wydawać abstrakcyjne. Dlatego aby wytłumaczyć ideę zarządzania
konfiguracją oraz pokazać szereg problemów, jakie pojawiają się w przypadku
pracy wielu osób, nad wieloma programami, dla wielu klientów…

3

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (3)

Wprowadzenie - problemy

• Różnorodność artefaktów

– specyfikacja wymagań
– kod źródłowy
– testy jednostkowe
– prototyp
– projekt
– …

Pierwszy problem to różnorodność artefaktów, nad którymi trzeba
„zapanować” podczas trwania projektów informatycznych. Są to różnego
rodzaju dokumenty, specyfikacja wymagań, prototyp, pomiary, projekt
architektury (np. UML), a wreszcie kod i przypadki testowe. Każdy z tych
artefaktów jest innego typu: np. kod i skrypty testowe są zapisane w plikach
tekstowych, dokumenty będą pamiętane jako pliki binarne. Prototyp może być
zrobiony w formie prezentacji PowerPointa, itp.

4

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (4)

Wprowadzenie - problemy

• Równoległa, wspólna praca nad

fragmentami kodu

Załóżmy, że nad pewnymi artefaktami (np. moduł kodu) pracuje wiele osób
jednocześnie.
Na diagramie mamy przykład, w którym nad programem (pakiet OpenOffice)
pracują 3 osoby. Każda z nich rozwija samodzielnie swój moduł, lecz pewne
elementy są wspólne (moduł ten został nazwany OpenOffice Core). Podczas
pracy nad poszczególnymi modułami często zachodzi potrzeba zmiany
modułu Core. Wtedy dochodzi do jednoczesnej pracy kilku osób nad tym
samym artefaktem.
Tak więc drugim problemem jest równoległa praca wielu osób - system
zarządzania konfiguracją musi wiedzieć, w jaki sposób pobrać zmiany od
poszczególnych programistów, następnie je scalić w jedno, a spójną wersję
rozpropagować dalej do pozostałych osób.

5

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (5)

Wprowadzenie - problemy

• Wiele wersji artefaktów:

– identyfikacja, przechowywanie

Każdy artefakt może ulegać ewolucji. Np. specyfikacja wymagań, lub projekt
architektury zmienia się w zależności od aktualnej wiedzy analityka lub
architekta.
Aby komunikacja w zespole i pomiędzy zespołem a klientem przebiegała
bezproblemowo, musimy mieć możliwość:
-identyfikacji wersji artefaktów - musimy wiedzieć, że konkretnego dnia klient
dostał specyfikację wymagań w określonej wersji. Jeżeli w przyszłości pojawią
się jakieś pytania/wątpliwości będzie możliwość sprawdzenia, jak wyglądała
tamta wersja
-pokazywania zmian pomiędzy wersjami artefaktów - przykładowo jeżeli po
przeglądzie specyfikacji wymagań w wersji 1.0 poprawimy wszystkie
zauważone błędy i damy klientowi wersję 2.0 do przeglądu, to chcemy
zaoszczędzić klientowi czasu i zaznaczyć tylko te fragmenty, które się
zmieniły.
Warto zauważyć, że zmiany wersji poszczególnych artefaktów nie są
synchroniczne, czyli np. specyfikacja wymagań może powstać w wersji 2.0
pewnego dnia, natomiast projekt architektury w wersji 2.0 powstanie dopiero
tydzień później.

6

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (6)

Wprowadzenie - problemy

• Wersje artefaktów, a wersje produktu

Podobnie zmieniają się wersje różnych modułów oprogramowania (czy też
plików źródłowych).
Firma programistyczna musi wiedzieć, co znajduje się w określonej wersji
produktu.
Jest to konieczne w momencie kiedy zadzwoni do nas klient z problemem. W
tej sytuacji musimy potrafić jednoznacznie powiedzieć, które wersje plików
źródłowych wchodzą w skład jego produktu. Jeżeli tego nie wiemy, to w jakiej
wersji kodu zaczniemy szukać błędu zgłoszonego przez niego?

Czyli wymagamy od systemu zarządzania konfiguracją, aby zapamiętał, że
przykładowo OpenOffice w wersji 1.0 składał się z modułów: Spell Checker
1.1, Printing 1.2 oraz Document Layout 1.1.

7

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (7)

Wprowadzenie - problemy

• Analizowanie historii:

– Kto? Kiedy? Jaka zmiana?

Aby zapanować nad dużym zespołem programistycznym, musimy mieć
możliwość śledzenia wszystkich zmian w artefaktach projektu, czyli musimy
posiadać informację kto, kiedy i jaką zmianę wprowadził.
Jest to potrzebne w wielu sytuacjach:
-ukarania pracownika lub testera za jego błędy
-sprawdzenia - która osoba odpowiada za dany fragment kodu - aby zgłosić
się do niego z uwagami lub pytaniami
-analizowania produktywności w oparciu o liczbę linii kodu napisanych przez
konkretnego programistę (nie jest to najlepsza miara produktywności)

8

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (8)

Wprowadzenie - problemy

• Praca nad nową

wersją systemu i
poprawianie
błędów w starej

Problem pojawia się również w momencie kiedy jedną wersję systemu (np.
OpenOffice 1.0) udostępnimy użytkownikom i zaczniemy pracować nad nową
wersją (czyli zaczniemy dodawać nową funkcjonalność, która na początku nie
będzie jeszcze stabilna). Co w momencie kiedy użytkownicy zauważą błędy?
Powinniśmy je jak najszybciej poprawić i udostępnić nowe wydanie wersji
OpenOffice 1.0 (może ona być oznaczona np. 1.0.1), lecz nie chcemy włączać
tam nowych funkcji, które są przeznaczane dla wersji 2.0 i nie są jeszcze
stabilne.
Czyli system zarządzania konfiguracją musi dawać możliwość równoległej
pracy nad różnymi wersjami produktu - chcemy mieć możliwość pracy nad
nową wersją, ale również możliwość poprawienia drobnego błędu w starej
wersji.

9

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (9)

Wprowadzenie

• Narzędzia wspomagające zarządzanie

konfiguracją oprogramowania:

– CVS, Subversion, SourceSafe

• Procedury:

– kodowania
– wydawania nowej wersji
– poprawiania defektów
– łączenia różnych zmian

Jest wiele narzędzi, które wspomagają zarządzanie konfiguracją
oprogramowania, darmowe np. CVS, Subversion, czy komercyjne np.
Microsoft SourceSafe.
Każde z tych narzędzi działa na podobnej zasadzie - za pomocą
odpowiednich komend umożliwiają wprowadzanie zmian do centralnego
repozytorium, pamiętają zmiany artefaktów, umożliwiają synchronizowanie
wersji różnych osób, oraz tworzenie rozgałęzień i łączenie gałęzi.
Samo narzędzie jednak nie wystarcza. W każdej firmie potrzebny jest zestaw
procedur, które instruują w jaki sposób korzystać z tego narzędzia, czyli w jaki
sposób należy wprowadzać zmiany w kodzie, wydawać nową wersję,
poprawiać defekty w udostępnionych wersjach, czy też łączyć zmiany z
różnych wersji.

10

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (10)

Plan wykładu

• Wprowadzenie

• Operacje systemu CVS:

– pobieranie artefaktów
– wysyłanie zmian
– aktualizacja
– nadawanie etykiet
– rozgałęzianie/łączenie gałęzi

• Struktura plików projektu
• Wzorce zarządzania

konfiguracją

Po tym krótkim wprowadzeniu zostanie przedstawiony najpopularniejszy
system zarządzania konfiguracją oprogramowania: CVS. Po kolei zostaną
omówione podstawowe operacje na repozytorium. Następnie zostanie
przedstawiona przykładowa struktura plików projektu, pozwalająca uniknąć
bałaganu (przydatne zwłaszcza początkującym osobom przystępującym do
pracy grupowej).
Samo przedstawienie operacji to jeszcze za mało - użytkownik musi wiedzieć,
w jaki sposób wykorzystać te operacje do osiągnięcia zamierzonych celów.
Dlatego na końcu zostaną przedstawione wybrane wzorce zarządzania
konfiguracją.

11

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (11)

System CVS

• Centralny

serwer

• Pracownicy

„komunikują”
się za jego
pośrednictwem

CVS działa w architekturze klient-serwer. Centralne repozytorium projektu
znajduje się na serwerze, a wszyscy członkowie zespołu rozprowadzają swoje
zmiany jedynie poprzez repozytorium. Nie ma zatem potrzeby przenoszenia
artefaktów pomiędzy osobami w postaci dyskietek, płyt, emaili, itp.

12

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (12)

Lokalna przestrzeń robocza

• Lokalna

(prywatna)
kopia
wybranych
elementów
repozytorium

• Zmiany

wprowadzane lokalnie
- synchronizowane na żądanie

Każdy użytkownik repozytorium posiada na swoim komputerze prywatną kopię
elementów z repozytorium, na których pracuje. Kopia taka nazywana jest
lokalną przestrzenią roboczą i stanowi zbiór plików i folderów pobranych z
repozytorium.
Wszelkie prace odbywają się najpierw lokalnie i są wysyłane na żądanie do
repozytorium. Dopiero w momencie, kiedy zmiany się tam znajdą są one
widoczne dla pozostałych osób.

13

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (13)

Plan wykładu

• Wprowadzenie

• Operacje systemu CVS:

– pobieranie artefaktów
– wysyłanie zmian
– aktualizacja
– nadawanie etykiet
– rozgałęzianie/łączenie gałęzi

• Struktura plików projektu
• Wzorce zarządzania

konfiguracją

Zacznijmy od poznania sposobu pracy z repozytorium CVS, czyli
poszczególnych komend, jakie możemy wykonać.
Pierwsza czynność programisty, to pobieranie artefaktów.

14

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (14)

Początkowe pobieranie artefaktów

• pobieranie artefaktów

(ang. checkout)

Zanim programista ma możliwość współpracy z repozytorium musi utworzyć
na swoim komputerze przestrzeń roboczą i pobrać do niej wybrane artefakty z
repozytorium.
Czyni to raz, np. na początku prac implementacyjnych. Wcześniej ktoś musi
umieścić tam pewien szkielet plików i folderów, ale o tym później.
Do pobierania artefaktów służy komenda checkout. Jako parametr tej
komendy podajemy nazwę „modułu”, który chcemy pobrać, czyli nazwę
jednego z katalogów przechowywanych w repozytorium (w szczególności
może to być zawartość całego repozytorium oznaczana przez „.”)

15

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (15)

Plan wykładu

• Wprowadzenie

• Operacje systemu CVS:

– pobieranie artefaktów

– wysyłanie zmian
– aktualizacja
– nadawanie etykiet
– rozgałęzianie/łączenie gałęzi

• Struktura plików projektu
• Wzorce zarządzania

konfiguracją

Codzienna praca nad artefaktami sprowadza się do wprowadzania zmian w
lokalnej wersji roboczej oraz synchronizowania ich z repozytorium (wysyłanie
zmian lokalnych na serwer i pobieranie zmian z serwera poprzez aktualizację)

16

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (16)

Cykl aktualizacji/wysyłanie zmian

• aktualizacja/wysyłanie zmian

(ang. update/commit)

Cykl synchronizacji z repozytorium najlepiej przedstawić na diagramie.
Pobieranie zmian z serwera i wprowadzanie do lokalnej przestrzeni roboczej
robione jest przez polecenie „update”.
Natomiast w drugą stronę - wysłanie lokalnych zmian do repozytorium
wykonuje się dzięki poleceniu „commit”.
Ze zmianami wysyłanymi do repozytorium (polecenie „commit”) można
skojarzyć komentarz. Nadawanie komentarzy jest dobrą praktyką, gdyż
ułatwia innym osobom z zespołu szybkie zorientowanie się w dużej liczbie
zmian.
Komendy „update” i „commit” można wykonać na określonych fragmentach
projektu: na wybranym pliku, całym katalogu, lub całym projekcie - w
zależności od potrzeby.
Zaleca się, aby taki cykl synchronizacji powtarzany był jak najczęściej - co
najmniej raz dziennie. Po przyjściu do pracy programista powinien wykonać
komendę „update”, aby ściągnąć bieżące zmiany, a następnie przed wyjściem
z pracy wykonać „commit”.

17

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (17)

Linia rozwoju artefaktu

Serwer pamięta historię wszystkich zmian wszystkich artefaktów. Powiedzmy,
że przechowujemy plik Program.java. Repozytorium będzie pamiętać każdą
wersję tego pliku (a dokładniej - różnice pomiędzy tymi wersjami), jak również
datę każdej operacji i osobę, która dokonała zmiany.
Każda wersja jest oznaczona numerem. W CVSie są to numery 1.1, 1.2, 1.3,
itd. Numeracja jest inna jeżeli nie pracujemy na głównej gałęzi, ale więcej
informacji o tym będzie za chwilę.

18

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (18)

Równoległe uaktualnianie artefaktów

?

Do tej pory wszystko wydaje się proste. Pobieramy pliki, pracujemy na nich, a
następnie wysyłamy i pobieramy zmiany.
Zadanie repozytorium CVS wydaje się dużo trudniejsze, jeżeli dopuścimy
możliwość równoległej pracy wielu osób. Każda z tych osób może pracować
jednocześnie na tym samym pliku, nawet zmieniać te same fragmenty pliku.
Spróbujmy przyjrzeć się jak działają operacje update/commit, aby zrozumieć,
jak CVS zachowa się w takich sytuacjach.

19

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (19)

Równoległe uaktualnianie artefaktów

Najlepiej prześledzić to na przykładzie. Na slajdzie widać 4 główne części:
-po prawej stronie mamy repozytorium CVS, z zaznaczonym plikiem klasy
Program.java, oraz numerem jego najnowszej wersji
-po lewej stronie widzimy przestrzenie robocze 2 programistów: Adama i
Kazia. Na początku przestrzenie te są puste, gdyż nie zaczęli oni pracy z
repozytorium
-na dole slajdu znajduje się oś czasu, na której zaznaczone są poszczególne
wersje pliku Program.java - zgodnie z tym co jest przechowywane w
repozytorium.

Oboje zaczynając pracę nad plikiem Program.java, muszą stworzyć sobie jego
kopię lokalną (polecenie „checkout”).
Równie dobrze mogliby wykonać to polecenie na całym katalogu, lub
projekcie, ale dla prostoty tego przykładu ograniczymy się jedynie do jednego
pliku.

20

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (20)

Równoległe uaktualnianie artefaktów

W rezultacie każdy z nich otrzymuje plik Program.java w najnowszej wersji
(1.1).
Jest to zaznaczone w ich lokalnych przestrzeniach roboczych - tam też widać
wersję pliku lokalnego.

Następnie zarówno Adam jak i Kaziu wprowadzają swoje zmiany do pliku
Program.java. Na diagramie oznaczyłem zmienione pliki symbolem gwiazdki
przy ich nazwie.

21

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (21)

Równoległe uaktualnianie artefaktów

Adam próbuje wykonać polecenie „commit” - udaje się to bez problemu.
Serwer przechowuje jego zmiany, jednocześnie nadając nową wersję plikowi
Program.java (1.2) - widać to na dolnej osi.
Równocześnie CVS zaznacza, że w przestrzeni roboczej również mamy już
wersję 1.2.
Znika również gwiazdka przy nazwie pliku, co oznacza, że nie mamy już
żadnych zmian lokalnych, które by nie były na serwerze.

Przychodzi kolej na Kazia. On również chce zapisać swoje zmiany w
repozytorium i próbuje wykonać operację „commit”.

22

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (22)

Równoległe uaktualnianie artefaktów

up-to-date check failed!

Niestety, serwer CVS wykrywa, że Kaziu pracował na starszej wersji pliku.
Miał on w swojej przestrzeni roboczej wersję 1.1, podczas gdy na serwerze
była już wersja 1.2.
CVS protestuje komunikatem „up-to-date check failed”, co oznacza w wolnym
tłumaczeniu: „masz nieaktualną przestrzeń roboczą”

23

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (23)

Równoległe uaktualnianie artefaktów

W takich sytuacjach należy najpierw pobrać najnowsze zmiany z CVSa i
uaktualnić lokalny plik do nowej wersji komendą „update”.
„Update” pobiera z CVSa zmiany pomiędzy wersją 1.1, a 1.2 i wprowadza je
do lokalnej przestrzeni roboczej Kazia, lecz nadal zachowuje jego własne
zmiany - co jest zaznaczona gwiazdką.

24

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (24)

Równoległe uaktualnianie artefaktów

Dopiero teraz Kaziu może wykonać komendę „commit”, która tym razem się
powiedzie. Skutkuje to zapamiętaniem zmian Kazia przez repozytorium i
nadanie nowej wersji (1.3).

25

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (25)

Równoległe uaktualnianie artefaktów

• Jak CVS wykonuje komendę update?

– zmiany po stronie lokalnej przestrzeni roboczej
– zmiany w repozytorium

*

?

Powstaje pytanie - jak CVS radzi sobie z wykonaniem komendy „update” w
momencie kiedy występują zmiany zarówno po stronie serwera, jak i lokalnie?
Musi on w jakiś sprytny sposób połączyć 2 różne pliki w jedno.
Sposób jest dosyć prosty - CVS próbuje scalić zmiany.

26

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (26)

Zmiany

lokalne

Zmiany z

repozytorium

Równoległe wprowadzanie zmian

• Zmiany lokalne i z repozytorium nie

nakładają się:

Zmiany są

łączone

Każdy plik tekstowy jest postrzegany przez CVS jako zbiór linii. Jeżeli linie
zmienione lokalnie oraz w repozytorium stanowią rozłączne obszary, wtedy nic
nie stoi na przeszkodzie, aby CVS automatycznie scaliło zmiany. W wyniku
powstaje plik, który zawiera zarówno zmiany lokalne, jak i globalne.

27

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (27)

Zmiany

lokalne

Zmiany z

repozytorium

Równoległe wprowadzanie zmian

• Zmiany lokalne i z repozytorium

nakładają się:

Konflikt!

Użytkownik

sam wybiera

właściwą wersję

Sytuacja się komplikuje, jeżeli zmienione linie lokalne i zdalne nakładają się.
Wtedy CVS nie jest w stanie ich automatycznie połączyć - prosi o pomoc
użytkownika.
Wtedy w pliku wynikowym przechowywane są obie wersje i są one oznaczane
jako tzw. konflikt. W takiej sytuacji użytkownik musi samodzielnie wybrać
właściwą wersję.

28

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (28)

Rozwiązywanie konfliktu

int main(int argc, char **argv) {

if (nerr == 0)

gencode();

else

fprintf(stderr, "No code generated.\n");

<<<<<<< driver.c

exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);

=======

exit(!!nerr);

>>>>>>> 1.6
}

Twoja

wersja

Wersja z

repozytorium

CVS oznacza konflikt w następujący sposób. Po wykonaniu komendy „update”
prowadzącej do konfliktu w pliku wynikowym mamy dwa bloki tekstu:
-jeden zaczyna się znakami „<<<<<<< nazwa_pliku”, a kończy „=======„ - to
jest wersja zmian z lokalnej przestrzeni roboczej
-drugi zaczyna się „========„, a kończy „>>>>>>> numer_wersji” - taki blok
oznacza zmiany z repozytorium (podany numer wersji oznacza wersję pliku, z
której zmiana pochodzi)
Zadaniem użytkownika w tej sytuacji jest wybór odpowiedniej wersji (czasem
to będzie jakieś połączenie obu wersji), oraz usunięcie wszelkich znaków
specjalnych oznaczających konflikt, a zostawienie jedynie poprawnej części
pliku.

29

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (29)

Narzędzia pomagające rozwiązywać konflikty

Współczesne narzędzia wspomagające rozwój oprogramowania (np. IBM
Eclipse) często ukrywają przed użytkownikiem symbole oznaczające konflikt,
prezentując konflikty w formie graficznej. Dzięki temu można w prosty sposób
porównać dwie wersje i stworzyć jedną wersję spójną.

30

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (30)

Plan wykładu

• Wprowadzenie

• Operacje systemu CVS:

– pobieranie artefaktów
– wysyłanie zmian
– aktualizacja

– nadawanie etykiet
– rozgałęzianie/łączenie gałęzi

• Struktura plików projektu
• Wzorce zarządzania

konfiguracją

Kolejna operacja, to nadawanie etykiet wersjom plików będących w
repozytorium CVS.

31

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (31)

Nadawanie etykiet

• Pozwala posługiwać się nazwami, zamiast

numerami wersji:

– oznaczanie wydań (np.: R_1.0, R_2.0)
– oznaczanie kodu w przypadku większych

zmian

Posługiwanie się numerami wersji plików w wielu sytuacjach byłoby kłopotliwe,
tym bardziej jeżeli musielibyśmy zapamiętać różne wersje wielu plików. Jest to
ważne np. do oznaczania zestawów plików, które wchodzą w skład pewnego
wydania oprogramowania. Również w przypadku wprowadzania większych
zmian do wielu plików na raz - dobrze jest pamiętać wersje tych plików, aby w
razie czego mieć możliwość cofnięcia zmian.

Z tego powodu systemy do zarządzania konfiguracją oprogramowania
(również CVS) pozwalają posługiwać się etykietami, zamiast numerami.
Etykiety są przydzielane świadomie przez programistę, wtedy kiedy uważa on
to za stosowne (np. w sytuacjach wspomnianych wcześniej). Są one
pamiętane przez repozytorium i za ich pomocą można pobrać określoną
wersję plików, które nas interesują.

32

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (32)

Plan wykładu

• Wprowadzenie

• Operacje systemu CVS:

– pobieranie artefaktów
– wysyłanie zmian
– aktualizacja
– nadawanie etykiet

– rozgałęzianie/łączenie gałęzi

• Struktura plików projektu
• Wzorce zarządzania

konfiguracją

Ostatnie 2, ale jedne z najważniejszych operacji w przypadku dużego zespołu
pracującego nad produktem regularnie wydawanym do klientów, to możliwość
rozgałęziania i łączenia gałęzi.

33

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (33)

Rozgałęzianie/łączenie gałęzi

• Rozdzielenie pracy nad pewną częścią

kodu:

– rozwój nowych funkcji/poprawki do starej

wersji

– dłuższe eksperymenty na kodzie

CVS umożliwia tworzenie rozgałęzień poprzez komendę „branch” i łączenia
poprzez „merge”.
Daje to możliwość wyłączenia fragmentu kodu z głównej linii rozwoju,
osobnego operowania na tej wydzielonej gałęzi, a następnie scalenia zmian z
główną gałęzią. Dobrze przedstawia to diagram ze slajdu.
W CVS-ie każda gałąź ma swoją nazwę (np. V_1_0), oraz numer złożony z
numeru pliku podstawowego (np. 1.2), oraz numeru parzystego
oznaczającego numer gałęzi (2, 4, 6,…). W rezultacie otrzymujemy 1.2.2 jako
numer gałęzi z przykładowego diagramu.
Kolejne numery wersji plików z gałęzi, mają na początku numer, oraz kolejno
1,2,3, na końcu.
Po wykonaniu niezbędnych zmian na gałęzi i przetestowaniu ich mamy
możliwość scalenia tych zmian z bazowym kodem poprzez wykonanie
komendy „merge”.

34

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (34)

Plan wykładu

• Wprowadzenie
• Operacje systemu CVS:

– pobieranie artefaktów
– wysyłanie zmian
– aktualizacja
– nadawanie etykiet
– rozgałęzianie/łączenie gałęzi

• Struktura plików projektu
• Wzorce zarządzania

konfiguracją

35

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (35)

Struktura plików projektu

• Różnorodność artefaktów:

– kod źródłowy
– skompilowany kod
– testy jednostkowe
– dokumenty
– projekt UML
– dodatkowe biblioteki
– grafika

• Jak to ogarnąć?

Jak było wspomniane na początku - w każdym projekcie mamy wielką
różnorodność artefaktów, które przechowujemy w repozytorium. Początkowi
programiści mają problem z odpowiednim rozmieszczeniem tych artefaktów.
Jeżeli zastanawiasz się nad tym, w jaki sposób to zrobić, najlepiej przejrzeć
struktury plików kilku przykładowych projektów Open-Source.

36

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (36)

Struktura plików projektu - Java

• bin
• doc

– design

• images
• lib
• src

– org.blabla.*

• tests

skompilowany kod - tylko lokalnie!

dokumentacja

UML

pliki graficzne wykorzystywane w kodzie

dodatkowe biblioteki: *.jar

kod źródłowy aplikacji, podział na pakiety

kod źródłowy testów jednostkowych

Dla języka Java, najczęstsza struktura plików projektu wygląda następująco:
-katalog bin zawiera skompilowany kod - ten katalog przechowywany jest tylko
lokalnie - nie powinniśmy go dodawać do CVS’a, gdyż z łatwością można te
pliki uzyskać na podstawie plików źródłowych, a umieszczenie ich w
repozytorium skutkowałoby dużą ilością konfliktów
-katalog doc - zawiera dokumenty projektu, lub dokumentację użytkownika
-w katalogu lib umieszcza się biblioteki zewnętrzne, z których projekt korzysta
(pliki *.jar)
-w src znajdują się pliki źródłowe, uporządkowane w pakietach
-katalog tests natomiast zawiera pliki źródłowe testów jednostkowych
napisanych za pomocą JUnita - takie rozdzielenie jest o tyle korzystne, że w
momencie budowania wersji dla klienta nie musimy zamieszczać tych plików
w wydaniu.

37

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (37)

Plan wykładu

• Wprowadzenie
• Operacje systemu CVS:

– pobieranie artefaktów
– wysyłanie zmian
– aktualizacja
– nadawanie etykiet
– rozgałęzianie/łączenie gałęzi

• Struktura plików projektu

• Wybrane wzorce

zarządzania konfiguracją

Znajomość samych operacji nie wystarcza jednak do rozwiązania wszystkich
problemów, o których była mowa na początku wykładu. Jest z tym podobnie
jak z językami programowania - znajomość konstrukcji języka nie jest
wystarczająca do budowania dużych systemów informatycznych.
Literatura udostępnia wiele dobrych praktyk i rad dotyczących posługiwaniem
się repozytorium kodu. Część z nich wyodrębniono jako „wzorce zarządzania
konfiguracją”. Wybrane wzorce zostaną przedstawione w dalszej części
wykładu.

38

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (38)

Wybrane wzorce zarządzania konfiguracją

• Główna linia

Mainline

• Linia wydania

Release Line

– Gałąź przed wydaniem

Release-Prep Codeline

• Gałęzie dla zadań

Branch per Task

Cztery najważniejsze wzorce, to:
-główna linia
-linia wydania
-gałąź przed wydaniem
-gałęzie dla zadań
Nazwy te w tej chwili mogą być dla Państwa niezrozumiałe, lecz za moment
powinno być wszystko jasne.

39

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (39)

Główna linia (ang. Mainline)

• Wiele gałęzi - drzewo może się rozrastać

w nieskończoność

Pierwszy wzorzec został nazwany „główną linią”.
Repozytoria umożliwiają dzielenie artefaktów na wiele gałęzi. Jednak duża
liczba tych gałęzi utrudnia panowanie nad repozytorium. Przy takiej strukturze
repozytorium, jak na diagramie, programiści mieliby problemy z odnalezieniem
właściwej gałęzi do pracy. Dodatkowo, po wydaniu nowej wersji produktu,
musieliby pamiętać, aby przełączyć się do gałęzi z nową wersją.
Dlatego nie jest pożądane, aby drzewo rozrastało się w głąb.

40

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (40)

Główna linia (ang. Mainline)

• Zamiast tego: utrzymuj „gałąź bazową”

Dużo lepszą praktyką jest utrzymywanie „gałęzi” bazowej, tzw. „głównej linii”.
Główne prace implementacyjne powinny odbywać się właśnie tam. Jeżeli
potrzebne jest rozgałęzienie i prowadzenie równoległych prac nad kawałkiem
kodu (np. w momencie wydania nowej wersji), to wszystkie zmiany powinny
docelowo być scalone z główną linią.
Takie podejście pozwala zapanować nad rozrastaniem się drzewa gałęzi i
odciąża wszystkich programistów od potrzeby pamiętania, w którym miejscu
drzewa obecnie się znajdujemy.

41

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (41)

Linia wydania (ang. Release Line)

• Linia reprezentująca logiczne grupowanie

dostarczonej funkcjonalności

Wybrana

funkcjonalność

Nowa funkcjonalność -

niestabilna

Poprawki dla klienta

wersji 1.0

Kolejny wzorzec to „linia wydania”.
Każdemu wydaniu systemu (np. nowa wersja oprogramowania) powinno
towarzyszyć rozgałęzienie. Dzięki temu część funkcjonalności, która była
zawarta w tym wydaniu jest „oddzielona” i można na niej prowadzić
równolegle pracę. Jest to niezbędne jeżeli chcemy pozwolić na tworzenie
nowej funkcjonalności (na początku niestabilnej) w głównej gałęzi, a
jednocześnie poprawiać błędy w wydanej wersji systemu.
Wtedy wszystkie błędy poprawiane są w gałęzi. W razie potrzeby można tą
strukturę bardziej zagnieżdżać - czyli zrobić gałąź dla gałęzi - gdy przykładowo
chcemy wydać wersję 1.1 oprogramowania, co jest pokazane na diagramie.

42

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (42)

Gałąź przed wydaniem (ang. Release-Prep Codeline)

• Część osób wcześniej skończy pracę nad

wersją

• Aby ich nie blokować do czasu wydania,

stwórz gałąź przed wydaniem

Następny wzorzec to „gałąź przed wydaniem”.
Problem powstaje, kiedy większy zespół pracuje nad wydaniem. Jeżeli część z
tych osób skończy pracę kilka dni wcześniej niż inni - wtedy chcieliby zapewne
zacząć już pracę nad nowymi funkcjami, lecz nie mogą tego robić w głównej
gałęzi - zakłóciliby pracę osób, które pracują nad wydaniem. W takiej sytuacji
zalecane jest stworzenie dodatkowej gałęzi. Na tej gałęzi pracują osoby
przygotowujące wydanie, natomiast pozostałe osoby mogą swobodnie
pracować w głównej gałęzi.

43

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (43)

Gałęzie dla zadań (ang. Branch per Task)

• Wiele zmian wprowadzanych w ramach

dłuższego zadania może tymczasowo naruszyć
spójność kodu

• Dla większych zadań twórz osobne gałęzie

Ostatni wzorzec to: „gałęzie dla zadań”.
Problem, z jakim można się często spotkać w praktyce to praca nad dłuższymi
zadaniami, która mocno zaburza pozostały kod. Wykonywanie tych zadań na
głównej gałęzi byłoby uciążliwe, gdyż w międzyczasie, przed ukończeniem
tego zadania zdarza się, że jakiś fragment się nie kompiluje, lub nie działa tak
jak powinien. W celu umożliwienia pracy nad takimi zadaniami należy dla
każdego stworzyć osobną gałąź. Po skończeniu zadania i upewnieniu się, iż
zmiany nie zaburzają istniejącego kodu można scalić je do głównej gałęzi.

44

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (44)

Podsumowanie

• Odpowiednie zarządzanie

konfiguracją jest niezbędne

do efektywnej pracy zespołowej

• Komendy systemu CVS

(checkout, update, commit)

– rozwiązywanie konfliktów

• Wybrane wzorce zarządzania

konfiguracją

Podsumowując:
-podczas rozproszonej pracy wielu osób nad projektem informatycznym
pojawia się wiele problemów związanych z zarządzaniem konfiguracją:
problemy z rozprowadzeniem zmian, ze scaleniem zmian z różnych miejsc w
jedno, z jednoczesną pracą wielu osób nad jednym plikiem.
-można je rozwiązać stosując odpowiednie narzędzia zarządzania
konfiguracją oprogramowania (np. repozytoria CVS)
-użytkownik narzędzia musi znać podstawowe komendy systemu,
umożliwiające współpracę z repozytorium (checkout, update, commit, branch,
merge), oraz pewne procedury pozwalające na zapanowanie nad dużą liczbą
zmian/wersji w projektach informatycznych. Są to wzorce zarządzania
konfiguracją, z których część została przedstawiona w trakcie tego wykładu

45

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania (45)

Literatura

•

http://cvsbook.red-bean.com/

• Steve Berczuk, Brad Appleton:

Software Configuration Management
Patterns

Osoby bardziej zainteresowane tą tematyką odsyłam do literatury.
Na temat obsługi narzędzi do zarządzania konfiguracją (np. CVS) można
poczytać w wielu miejscach w Internecie. Na slajdzie jest pokazany
przykładowy adres.
Bardzo dobrą pozycją opisującą różne niuanse zarządzania konfiguracją oraz
szereg wzorców jest książka Software Configuration Management Patterns.