Zarządzanie konfiguracją oprogramowania 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. Autor: Łukasz Olek

Zasady skutecznego działania Specyfikacja wymagań 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 wykładów inżynierii oprogramowania. Do tej pory dowiedzieliśmy się 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. 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ą postaram się pokazać szereg problemów, jakie pojawiają się w przypadku pracy wielu osób, nad wieloma programami, dla wielu klientów…

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. Dą 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.

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.

Wprowadzenie - problemy Wiele wersji artefaktów: identyfikacja, przechowywanie Każdy artefakt może ulegać ewolucji. Np. specyfikacja wymań, 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.

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.

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 mieć 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 napisanego przez konkretnego programistę (nie jest to najlepsza miara produktywności)

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 dla użytkowników 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.

Narzędzia wspomagające zarządzanie konfiguracją oprogramowania: 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, np. darmowe 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 do kodu, wydawać nową wersję, poprawiać defekty w udostępnionych wersjach, czy też łączyć zmiany z różnych wersji.

Struktura plików projektu Wzorce zarządzania konfiguracją 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ć jak wykorzystać te operacje do osiągnięcia zamierzonych celów. Dlatego na końcu zostaną przedstawione wybrane wzorce zarządzania konfiguracją.

Pracownicy „komunikują” się za jego pośrednictwem 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.

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ą sie 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.

Struktura plików projektu Wzorce zarządzania konfiguracją 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.

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 szególności może to być zawartość całego repozytorium oznaczana przez „.”)

Struktura plików projektu Wzorce zarządzania konfiguracją 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 synchronizowanie ich z repozytorium (wysyłanie zmian lokalnych na serwer i pobieranie zmian z serwera poprzez aktualizację) 

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”.

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ę.

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 wejść głębiej w operacje update/commit, aby zrozumieć jak CVS zachowa się w takich sytuacjach.

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ą pracę nad plikiem Program.java, poprzez stworzenie jego kopii lokalnej (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.

Równoległe uaktualnianie arteraktó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.

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”.

Równoległe uaktualnianie artefaktów 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ą” up-to-date check failed!

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ą.

Równoległe uaktualnianie artefaktów Dopiero wtedy 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).

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. ? *

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. Zmiany lokalne Zmiany z repozytorium

Równoległe wprowadzanie zmian Zmiany lokalne i z repozytorium nakładają się: Konflikt! 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ę. Użytkownik sam wybiera właściwą wersję Zmiany lokalne Zmiany z repozytorium

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 } 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. Twoja wersja Wersja z repozytorium

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ą.

Struktura plików projektu Wzorce zarządzania konfiguracją 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.

Pozwala posługiwać się nazwami, zamiast numerami wersji: 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ą.

Struktura plików projektu Wzorce zarządzania konfiguracją 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.

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 gałęzi, 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”.

Sprawdzenie wiadomości

Struktura plików projektu Wzorce zarządzania konfiguracją 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ą

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.

Struktura plików projektu - Java skompilowany kod - tylko lokalnie! bin doc design images lib src org.blabla.* tests dokumentacja UML pliki graficzne wykorzystywane w kodzie dodatkowe biblioteki: *.jar kod źródłowy aplikacji, podział na pakiety 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. kod źródłowy testów jednostkowych

Struktura plików projektu Wybrane wzorce zarządzania konfiguracją 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.

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 nic Państwu nie znaczą, lecz za moment powinno być wszystko jasne.

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ą. Rodziłoby to dużo problemów. Dlatego nie jest pożądane, aby drzewo rozrastało się w głąb.

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.

Linia wydania (ang. Release Line) Linia reprezentująca logiczne grupowanie dostarczonej funkcjonalności Poprawki dla klienta wersji 1.0 Wybrana funkcjonalność 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. Nowa funkcjonalność - niestabilna

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.

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łaby uciążliwa, 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.

Komendy systemu CVS (checkout, update, commit) 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

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ącym różne niuanse zarządzania konfiguracją oraz szereg wzorców jest książka Software Configuration Management Patterns.