Zarządzanie konfiguracją oprogramowania Autor: Łukasz Olek Witam Państwa serdecznie na wykładzie poświęconym zarządzaniu konfiguracją oprogramowania. 1
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 Zarządzanie konfiguracją oprogramowania (2) 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 2
Wprowadzenie - problemy Różnorodność artefaktów specyfikacja wymagań kod źródłowy testy jednostkowe prototyp projekt Zarządzanie konfiguracją oprogramowania (3) 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. 3
Wprowadzenie - problemy Równoległa, wspólna praca nad fragmentami kodu Zarządzanie konfiguracją oprogramowania (4) 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. 4
Wprowadzenie - problemy Wiele wersji artefaktów: identyfikacja, przechowywanie Zarządzanie konfiguracją oprogramowania (5) 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. 5
Wprowadzenie - problemy Wersje artefaktów, a wersje produktu Zarządzanie konfiguracją oprogramowania (6) 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. 6
Wprowadzenie - problemy Analizowanie historii: Kto? Kiedy? Jaka zmiana? Zarządzanie konfiguracją oprogramowania (7) 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) 7
Wprowadzenie - problemy Praca nad nową wersją systemu i poprawianie błędów w starej Zarządzanie konfiguracją oprogramowania (8) 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. 8
Wprowadzenie Narzędzia wspomagające zarządzanie konfiguracją oprogramowania: CVS, Subversion, SourceSafe Procedury: kodowania wydawania nowej wersji poprawiania defektów łączenia różnych zmian Zarządzanie konfiguracją oprogramowania (9) 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. 9
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ą Zarządzanie konfiguracją oprogramowania (10) 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ą. 10
System CVS Centralny serwer Pracownicy komunikują się za jego pośrednictwem Zarządzanie konfiguracją oprogramowania (11) 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. 11
Lokalna przestrzeń robocza Lokalna (prywatna) kopia wybranych elementów repozytorium Zmiany wprowadzane lokalnie - synchronizowane na żądanie Zarządzanie konfiguracją oprogramowania (12) 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. 12
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ą Zarządzanie konfiguracją oprogramowania (13) Zacznijmy od poznania sposobu pracy z repozytorium CVS, czyli poszczególnych komend, jakie możemy wykonać. Pierwsza czynność programisty, to pobieranie artefaktów. 13
Początkowe pobieranie artefaktów pobieranie artefaktów (ang. checkout) Zarządzanie konfiguracją oprogramowania (14) 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. ) 14
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ą Zarządzanie konfiguracją oprogramowania (15) 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ę) 15
Cykl aktualizacji/wysyłanie zmian aktualizacja/wysyłanie zmian (ang. update/commit) Zarządzanie konfiguracją oprogramowania (16) 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. 16
Linia rozwoju artefaktu Zarządzanie konfiguracją oprogramowania (17) 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ę. 17
Równoległe uaktualnianie artefaktów? Zarządzanie konfiguracją oprogramowania (18) 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. 18
Równoległe uaktualnianie artefaktów Zarządzanie konfiguracją oprogramowania (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 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. 19
Równoległe uaktualnianie artefaktów Zarządzanie konfiguracją oprogramowania (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 pliku Program.java. Na diagramie oznaczyłem zmienione pliki symbolem gwiazdki przy ich nazwie. 20
Równoległe uaktualnianie artefaktów Zarządzanie konfiguracją oprogramowania (21) 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. 21
Równoległe uaktualnianie artefaktów up-to-date check failed! Zarządzanie konfiguracją oprogramowania (22) 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ą 22
Równoległe uaktualnianie artefaktów Zarządzanie konfiguracją oprogramowania (23) 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ą. 23
Równoległe uaktualnianie artefaktów Zarządzanie konfiguracją oprogramowania (24) 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). 24
Równoległe uaktualnianie artefaktów Jak CVS wykonuje komendę update? zmiany po stronie lokalnej przestrzeni roboczej zmiany w repozytorium *? Zarządzanie konfiguracją oprogramowania (25) 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. 25
Równoległe wprowadzanie zmian Zmiany lokalne i z repozytorium nie nakładają się: Zmiany są łączone Zmiany Zmiany z lokalne repozytorium Zarządzanie konfiguracją oprogramowania (26) 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. 26
Równoległe wprowadzanie zmian Zmiany lokalne i z repozytorium nakładają się: Konflikt! Zmiany Zmiany z lokalne repozytorium Użytkownik sam wybiera właściwą wersję Zarządzanie konfiguracją oprogramowania (27) 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ę. 27
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 } Wersja z repozytorium Twoja wersja Zarządzanie konfiguracją oprogramowania (28) 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. 28
Narzędzia pomagające rozwiązywać konflikty Zarządzanie konfiguracją oprogramowania (29) 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ą. 29
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ą Zarządzanie konfiguracją oprogramowania (30) Kolejna operacja, to nadawanie etykiet wersjom plików będących w repozytorium CVS. 30
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 Zarządzanie konfiguracją oprogramowania (31) 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ą. 31
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ą Zarządzanie konfiguracją oprogramowania (32) 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. 32
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 Zarządzanie konfiguracją oprogramowania (33) 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. 33
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ą Zarządzanie konfiguracją oprogramowania (34) 34
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ąć? Zarządzanie konfiguracją oprogramowania (35) 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. 35
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 Zarządzanie konfiguracją oprogramowania (36) 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. 36
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ą Zarządzanie konfiguracją oprogramowania (37) 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. 37
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 Zarządzanie konfiguracją oprogramowania (38) 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. 38
Główna linia (ang. Mainline) Wiele gałęzi - drzewo może się rozrastać w nieskończoność Zarządzanie konfiguracją oprogramowania (39) 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. 39
Główna linia (ang. Mainline) Zamiast tego: utrzymuj gałąź bazową Zarządzanie konfiguracją oprogramowania (40) 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. 40
Linia wydania (ang. Release Line) Linia reprezentująca logiczne grupowanie dostarczonej funkcjonalności Wybrana funkcjonalność Poprawki dla klienta wersji 1.0 Nowa funkcjonalność - niestabilna Zarządzanie konfiguracją oprogramowania (41) 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. 41
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 Zarządzanie konfiguracją oprogramowania (42) 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. 42
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 Zarządzanie konfiguracją oprogramowania (43) 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. 43
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ą Zarządzanie konfiguracją oprogramowania (44) 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 44
Literatura http://cvsbook.red-bean.com/ Steve Berczuk, Brad Appleton: Software Configuration Management Patterns Zarządzanie konfiguracją oprogramowania (45) 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. 45