Autor: Łukasz Olek - Studia Informatycznewazniak.mimuw.edu.pl/images/5/5e/Io-9-wyk-bw.pdf · Inżynieria oprogramowania Zarządzanie konfiguracją oprogramowania Autor: Łukasz Olek

1

Inżynieria oprogramowania

Zarządzanie konfiguracją oprogramowania

Autor: Łukasz Olek

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

2


Zarządzanie konfiguracją oprogramowania (2)

Plan wykładów

Zasady skutecznego działaniaSpecyfikacja wymagańKontrola jakości artefaktówJęzyk UML, cz. IJęzyk UML, cz. IIMetody formalneWzorce projektoweZarządzanie konfiguracjąWprowadzenie do testowaniaAutomatyzacja wykonywania testówProgramowanie EkstremalneEwolucja oprogramowania i refaktoryzacja

Jest to ósmy wykład z cyklu.Dowiedzieliśmy się już o takich zagadnieniach jak przygotowywaniespecyfikacji wymagań, projektowaniu w języku UML, poznaliśmy wzorceprojektowe… Obecny wykład pomoże zrozumieć metody zapanowania nadtymi wszystkimi artefaktami i ich zmianami, jakie mają miejsce w projektachinformatycznych.

Zarządzanie konfiguracją oprogramowania to zestaw czynnościpozwalają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ądzaniakonfiguracją oraz pokazać szereg problemów, jakie pojawiają się w przypadkupracy wielu osób, nad wieloma programami, dla wielu klientów…

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óżnegorodzaju dokumenty, specyfikacja wymagań, prototyp, pomiary, projektarchitektury (np. UML), a wreszcie kod i przypadki testowe. Każdy z tychartefaktów jest innego typu: np. kod i skrypty testowe są zapisane w plikachtekstowych, dokumenty będą pamiętane jako pliki binarne. Prototyp może byćzrobiony w formie prezentacji PowerPointa, itp.

4




• Równoległa, wspólna praca nadfragmentami kodu

Załóżmy, że nad pewnymi artefaktami (np. moduł kodu) pracuje wiele osóbjednocześ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 pewneelementy są wspólne (moduł ten został nazwany OpenOffice Core). Podczaspracy nad poszczególnymi modułami często zachodzi potrzeba zmianymodułu Core. Wtedy dochodzi do jednoczesnej pracy kilku osób nad tymsamym artefaktem.Tak więc drugim problemem jest równoległa praca wielu osób - systemzarządzania konfiguracją musi wiedzieć, w jaki sposób pobrać zmiany odposzczególnych programistów, następnie je scalić w jedno, a spójną wersjęrozpropagować dalej do pozostałych osób.

5




• Wiele wersji artefaktów:– identyfikacja, przechowywanie

Każdy artefakt może ulegać ewolucji. Np. specyfikacja wymagań, lub projektarchitektury zmienia się w zależności od aktualnej wiedzy analityka lubarchitekta.Aby komunikacja w zespole i pomiędzy zespołem a klientem przebiegałabezproblemowo, musimy mieć możliwość:-identyfikacji wersji artefaktów - musimy wiedzieć, że konkretnego dnia klientdostał 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łatamta wersja-pokazywania zmian pomiędzy wersjami artefaktów - przykładowo jeżeli poprzeglądzie specyfikacji wymagań w wersji 1.0 poprawimy wszystkiezauważone błędy i damy klientowi wersję 2.0 do przeglądu, to chcemyzaoszczę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.0pewnego dnia, natomiast projekt architektury w wersji 2.0 powstanie dopierotydzień później.

6




• 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 wersjiproduktu.Jest to konieczne w momencie kiedy zadzwoni do nas klient z problemem. Wtej 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 jakiejwersji kodu zaczniemy szukać błędu zgłoszonego przez niego?

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

7




• 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 musimyposiadać 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 przezkonkretnego programistę (nie jest to najlepsza miara produktywności)

8




• Praca nad nowąwersją systemu ipoprawianiebłę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 niebędzie jeszcze stabilna). Co w momencie kiedy użytkownicy zauważą błędy?Powinniśmy je jak najszybciej poprawić i udostępnić nowe wydanie wersjiOpenOffice 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ą jeszczestabilne.Czyli system zarządzania konfiguracją musi dawać możliwość równoległejpracy nad różnymi wersjami produktu - chcemy mieć możliwość pracy nadnową wersją, ale również możliwość poprawienia drobnego błędu w starejwersji.

9



Wprowadzenie

• Narzędzia wspomagające zarządzaniekonfiguracją 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 centralnegorepozytorium, pamiętają zmiany artefaktów, umożliwiają synchronizowaniewersji różnych osób, oraz tworzenie rozgałęzień i łączenie gałęzi.Samo narzędzie jednak nie wystarcza. W każdej firmie potrzebny jest zestawprocedur, które instruują w jaki sposób korzystać z tego narzędzia, czyli w jakisposób należy wprowadzać zmiany w kodzie, wydawać nową wersję,poprawiać defekty w udostępnionych wersjach, czy też łączyć zmiany zróżnych wersji.

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 najpopularniejszysystem zarządzania konfiguracją oprogramowania: CVS. Po kolei zostanąomówione podstawowe operacje na repozytorium. Następnie zostanieprzedstawiona przykładowa struktura plików projektu, pozwalająca uniknąćbałaganu (przydatne zwłaszcza początkującym osobom przystępującym dopracy 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ądzaniakonfiguracją.

11



System CVS

• Centralnyserwer

• Pracownicy„komunikują”się za jegopośrednictwem

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

12



Lokalna przestrzeń robocza

• Lokalna(prywatna)kopiawybranychelementówrepozytorium

• Zmianywprowadzane 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 jestlokalną przestrzenią roboczą i stanowi zbiór plików i folderów pobranych zrepozytorium.Wszelkie prace odbywają się najpierw lokalnie i są wysyłane na żądanie dorepozytorium. Dopiero w momencie, kiedy zmiany się tam znajdą są onewidoczne dla pozostałych osób.

13



Plan wykładu




konfiguracją

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

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 zrepozytorium.Czyni to raz, np. na początku prac implementacyjnych. Wcześniej ktoś musiumieś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 tejkomendy podajemy nazwę „modułu”, który chcemy pobrać, czyli nazwęjednego z katalogów przechowywanych w repozytorium (w szczególnościmoże to być zawartość całego repozytorium oznaczana przez „.”)

15



Plan wykładu




konfiguracją

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

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 roboczejrobione jest przez polecenie „update”.Natomiast w drugą stronę - wysłanie lokalnych zmian do repozytoriumwykonuje się dzięki poleceniu „commit”.Ze zmianami wysyłanymi do repozytorium (polecenie „commit”) możnaskojarzyć komentarz. Nadawanie komentarzy jest dobrą praktyką, gdyżułatwia innym osobom z zespołu szybkie zorientowanie się w dużej liczbiezmian.Komendy „update” i „commit” można wykonać na określonych fragmentachprojektu: na wybranym pliku, całym katalogu, lub całym projekcie - wzależności od potrzeby.Zaleca się, aby taki cykl synchronizacji powtarzany był jak najczęściej - conajmniej raz dziennie. Po przyjściu do pracy programista powinien wykonaćkomendę „update”, aby ściągnąć bieżące zmiany, a następnie przed wyjściemz pracy wykonać „commit”.

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ęcejinformacji o tym będzie za chwilę.

18



Równoległe uaktualnianie artefaktów

?Do tej pory wszystko wydaje się proste. Pobieramy pliki, pracujemy na nich, anastępnie wysyłamy i pobieramy zmiany.Zadanie repozytorium CVS wydaje się dużo trudniejsze, jeżeli dopuścimymoż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




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

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

20




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 plikuProgram.java. Na diagramie oznaczyłem zmienione pliki symbolem gwiazdkiprzy ich nazwie.

21




Adam próbuje wykonać polecenie „commit” - udaje się to bez problemu.Serwer przechowuje jego zmiany, jednocześnie nadając nową wersję plikowiProgram.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 wrepozytorium i próbuje wykonać operację „commit”.

22




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 serwerzebyła już wersja 1.2.CVS protestuje komunikatem „up-to-date check failed”, co oznacza w wolnymtłumaczeniu: „masz nieaktualną przestrzeń roboczą”

23




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

24




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

25




• Jak CVS wykonuje komendę update?– zmiany po stronie lokalnej przestrzeni roboczej– zmiany w repozytorium

* ?

Powstaje pytanie - jak CVS radzi sobie z wykonaniem komendy „update” wmomencie 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



Zmiany lokalne

Zmiany z repozytorium

Równoległe wprowadzanie zmian

• Zmiany lokalne i z repozytorium nienakładają się:

Zmiany sąłączone

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

27



Zmiany lokalne

Zmiany z repozytorium

Równoległe wprowadzanie zmian

• Zmiany lokalne i z repozytoriumnakładają się:

Konflikt!

Użytkowniksam 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 pomocużytkownika.Wtedy w pliku wynikowym przechowywane są obie wersje i są one oznaczanejako tzw. konflikt. W takiej sytuacji użytkownik musi samodzielnie wybraćwłaściwą wersję.

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}

Twojawersja

Wersja zrepozytorium

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 „=======„ - tojest wersja zmian z lokalnej przestrzeni roboczej-drugi zaczyna się „========„, a kończy „>>>>>>> numer_wersji” - taki blokoznacza zmiany z repozytorium (podany numer wersji oznacza wersję pliku, zktórej zmiana pochodzi)Zadaniem użytkownika w tej sytuacji jest wybór odpowiedniej wersji (czasemto będzie jakieś połączenie obu wersji), oraz usunięcie wszelkich znakówspecjalnych oznaczających konflikt, a zostawienie jedynie poprawnej częścipliku.

29



Narzędzia pomagające rozwiązywać konflikty

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

30



Plan wykładu




konfiguracją

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

31



Nadawanie etykiet

• Pozwala posługiwać się nazwami, zamiastnumerami 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 toważne np. do oznaczania zestawów plików, które wchodzą w skład pewnegowydania oprogramowania. Również w przypadku wprowadzania większychzmian do wielu plików na raz - dobrze jest pamiętać wersje tych plików, aby wrazie 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 onto za stosowne (np. w sytuacjach wspomnianych wcześniej). Są onepamiętane przez repozytorium i za ich pomocą można pobrać określonąwersję plików, które nas interesują.

32



Plan wykładu




konfiguracją

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

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 łączeniapoprzez „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 zgłó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 znumeru pliku podstawowego (np. 1.2), oraz numeru parzystegooznaczającego numer gałęzi (2, 4, 6,…). W rezultacie otrzymujemy 1.2.2 jakonumer gałęzi z przykładowego diagramu.Kolejne numery wersji plików z gałęzi, mają na początku numer, oraz kolejno1,2,3, na końcu.Po wykonaniu niezbędnych zmian na gałęzi i przetestowaniu ich mamymożliwość scalenia tych zmian z bazowym kodem poprzez wykonaniekomendy „merge”.

34



Plan wykładu




konfiguracją

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ątkowiprogramiś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



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 tylkolokalnie - nie powinniśmy go dodawać do CVS’a, gdyż z łatwością można tepliki uzyskać na podstawie plików źródłowych, a umieszczenie ich wrepozytorium 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 jednostkowychnapisanych za pomocą JUnita - takie rozdzielenie jest o tyle korzystne, że wmomencie budowania wersji dla klienta nie musimy zamieszczać tych plikóww wydaniu.

37



Plan wykładu



• Struktura plików projektu• Wybrane wzorce

zarządzania konfiguracją

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

38



Wybrane wzorce zarządzania konfiguracją

• Główna liniaMainline

• Linia wydaniaRelease 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 momentpowinno być wszystko jasne.

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żaliczba tych gałęzi utrudnia panowanie nad repozytorium. Przy takiej strukturzerepozytorium, jak na diagramie, programiści mieliby problemy z odnalezieniemwł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



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żelipotrzebne jest rozgałęzienie i prowadzenie równoległych prac nad kawałkiemkodu (np. w momencie wydania nowej wersji), to wszystkie zmiany powinnydocelowo być scalone z główną linią.Takie podejście pozwala zapanować nad rozrastaniem się drzewa gałęzi iodciąża wszystkich programistów od potrzeby pamiętania, w którym miejscudrzewa obecnie się znajdujemy.

41



Linia wydania (ang. Release Line)

• Linia reprezentująca logiczne grupowaniedostarczonej funkcjonalności

Wybranafunkcjonalność

Nowa funkcjonalność -niestabilna

Poprawki dla klientawersji 1.0

Kolejny wzorzec to „linia wydania”.Każdemu wydaniu systemu (np. nowa wersja oprogramowania) powinnotowarzyszyć rozgałęzienie. Dzięki temu część funkcjonalności, która byłazawarta w tym wydaniu jest „oddzielona” i można na niej prowadzićrównolegle pracę. Jest to niezbędne jeżeli chcemy pozwolić na tworzenienowej funkcjonalności (na początku niestabilnej) w głównej gałęzi, ajednocześ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ładowochcemy wydać wersję 1.1 oprogramowania, co jest pokazane na diagramie.

42



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

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

• 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ęść ztych osób skończy pracę kilka dni wcześniej niż inni - wtedy chcieliby zapewnezacząć już pracę nad nowymi funkcjami, lecz nie mogą tego robić w głównejgałęzi - zakłóciliby pracę osób, które pracują nad wydaniem. W takiej sytuacjizalecane jest stworzenie dodatkowej gałęzi. Na tej gałęzi pracują osobyprzygotowujące wydanie, natomiast pozostałe osoby mogą swobodniepracować w głównej gałęzi.

43



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

• Wiele zmian wprowadzanych w ramachdł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ższymizadaniami, która mocno zaburza pozostały kod. Wykonywanie tych zadań nagłównej gałęzi byłoby uciążliwe, gdyż w międzyczasie, przed ukończeniemtego zadania zdarza się, że jakiś fragment się nie kompiluje, lub nie działa takjak powinien. W celu umożliwienia pracy nad takimi zadaniami należy dlakaż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



Podsumowanie

• Odpowiednie zarządzaniekonfiguracją jest niezbędnedo efektywnej pracy zespołowej

• Komendy systemu CVS(checkout, update, commit)– rozwiązywanie konfliktów

• Wybrane wzorce zarządzaniakonfiguracją

Podsumowując:-podczas rozproszonej pracy wielu osób nad projektem informatycznympojawia się wiele problemów związanych z zarządzaniem konfiguracją:problemy z rozprowadzeniem zmian, ze scaleniem zmian z różnych miejsc wjedno, z jednoczesną pracą wielu osób nad jednym plikiem.-można je rozwiązać stosując odpowiednie narzędzia zarządzaniakonfiguracją 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ądzaniakonfiguracją, z których część została przedstawiona w trakcie tego wykładu

45



Literatura

• http://cvsbook.red-bean.com/• Steve Berczuk, Brad Appleton:

Software Configuration ManagementPatterns

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

Documents

Autor: Łukasz Olek - Studia Informatycznewazniak.mimuw.edu.pl/images/5/5e/Io-9-wyk-bw.pdf · Inżynieria oprogramowania Zarządzanie konfiguracją oprogramowania Autor: Łukasz Olek