Praca Dyplomowa: Środowiska Ciągłej Integracji W Wytwarzaniu Oprogramowania

POLITECHNIKA WARSZAWSKA
PODYPLOMOWE STUDIUM
PROWADZENIA PROJEKTÓW INFORMATYCZNYCH
PRACA DYPLOMOWA
Grzegorz Ol˛edzki
Rok. akad. 2008/2009
TEMAT PRACY DYPLOMOWEJ:

Środowiska ciagłej
˛ integracji
w wytwarzaniu oprogramowania
Zakres pracy:
1. Wprowadzenie poj˛eć integracji i ciagłej
˛ integracji.
2. Schemat interakcji w środowisku ciagłej
˛ integracji.
3. Możliwości środowisk ciagłej
˛ integracji.
4. Korzyści i koszty wprowadzenia ciagłej
˛ integracji.
5. Praktyka wykorzystania ciagłej
˛ integracji.
6. Wnioski.
Opiekun naukowy:
dr inż. Włodzimierz Dabrowski
˛
Termin wykonania: sierpień 2009

Praca wykonana i zaliczona pozostaje własnościa˛ Uczelni i nie b˛edzie zwrócona wykonawcy.
ŚRODOWISKA CIAGŁEJ
˛ INTEGRACJI
w WYTWARZANIU OPROGRAMOWANIA
STRESZCZENIE
Ciagła
˛ integracja jest praktyka˛ coraz cz˛eściej stosowana˛ w projektach informa-
tycznych, zwłaszcza tych rozwijanych metodykami zwinnymi. Stanowi pomocne narz˛edzie
wspomagajace
˛ monitorowanie stanu rozwoju aplikacji, przyczyniajac
˛ si˛e do poprawy jakości
wytwarzanego oprogramowania.
Praca prezentuje poj˛ecie ciagłej
˛ integracji– poczawszy
˛ od genezy jego powstania.
Omówiono wachlarz możliwości oferowanych przez środowiska ciagłej
˛ integracji wraz z opi-
sem znaczenia poszczególnych elementów. Zanalizowano korzyści niesione przez ciagł
˛ a˛ in-
tegracj˛e oraz koszty, z jakimi trzeba si˛e liczyć przy jej wdrożeniu. Przedstawiono również
krótki opis trzech popularnych produktów – serwerów ciagłej
˛ integracji. Ważnym elementem
pracy jest także opis zbioru najlepszych praktyk, uznanych przez środowisko osób zwiaza-
˛
nych z ciagł
˛ a˛ integracja.˛ Praca przedstawia również propozycje praktycznego rozwiazania
˛
problemu skali – ważnego zwłaszcza przy zastosowaniach ciagłej
˛ integracji w wi˛ekszych
organizacjach.
CONTINUOUS INTEGRATION ENVIRONMENTS

IN SOFTWARE DEVELOPMENT
ABSTRACT
Continuous integration is a software development technique gaining in popularity,

especially in projects using agile methods. It’s a tool allowing for easier development progress
monitoring, improving the quality of produced software.
The thesis introduces the notion of continuous integration along with its origins. The
whole range of features offered by continuous integration environments and the values they
provide is described. The benefits and costs of continuous integration adoption are analyzed.
A brief description of three popular products, i.e. continuous integration servers is included.
Best practices set suggested by the community is presented. So are practical suggestions of
solution of the scale problem, which bigger organizations might find crucial.
Grzegorz Ol˛edzki, Środowiska ciagłej
˛ integracji w wytwarzaniu oprogramowania
Spis treści
Wst˛ep 5
1 Analiza środowisk ciagłej

˛ integracji 8
1.1 Schemat interakcji w środowisku ciagłej
˛ integracji . . . . . . . . . . . . . . 8
1.2 Warunki zastosowania ciagłej
˛ integracji . . . . . . . . . . . . . . . . . . . . 11
1.3 Możliwości środowisk ciagłej
˛ integracji . . . . . . . . . . . . . . . . . . . . 12
1.3.1 Odświeżanie kodu źródłowego . . . . . . . . . . . . . . . . . . . . . 15
1.3.2 Decyzja o zasadności kontynuowania integracji . . . . . . . . . . . . 15
1.3.3 Budowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.4 Testowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3.5 Przeglad
˛ kodu – statyczna analiza kodu . . . . . . . . . . . . . . . . 21
1.3.6 Uruchomienie aplikacji . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3.7 Testowanie interfejsu aplikacji . . . . . . . . . . . . . . . . . . . . . 25
1.3.8 Powiadomienie o wyniku integracji . . . . . . . . . . . . . . . . . . 27
1.3.9 Oznaczenie kodu źródłowego . . . . . . . . . . . . . . . . . . . . . 30
1.4 Produkty ciagłej
˛ integracji . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.5 Korzyści z zastosowania ciagłej
˛ integracji w wytwarzaniu oprogramowania . 34
1.5.1 Jakość tworzonego oprogramowania . . . . . . . . . . . . . . . . . . 34
1.5.2 Gotowość do użycia . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.5.3 Zarzadzanie
˛ zmianami . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.5.4 Usprawnienie procesów . . . . . . . . . . . . . . . . . . . . . . . . 36
1.6 Koszty wprowadzenia i utrzymania ciagłej
˛ integracji . . . . . . . . . . . . . 37
2 Praktyka wykorzystania ciagłej

˛ integracji 39
2.1 Wybrane rozwiazania
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.1.1 CruiseControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.1.2 Hudson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3 / 61
2.1.3 TeamCity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.2 Najlepsze praktyki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.3 Skalowalność . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.3.1 Klaster serwerów ciagłej
˛ integracji . . . . . . . . . . . . . . . . . . . 53
2.3.2 Budowanie etapowe . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Zakończenie 58
Bibliografia 60
4 / 61
Wst˛ep
Cel i zakres pracy
Celem pracy jest przybliżenie poj˛ecia „ciagłej

˛ integracji” i jej roli w procesie pro-
dukcji oprogramowania. We wst˛epie zostana˛ zarysowane poj˛ecia integracji i ciagłej
˛ inte-
gracji. W kolejnym rozdziale przedstawiono możliwości narz˛edzi wspierajacych
˛ ciagł
˛ a˛ in-
tegracj˛e. Nast˛epnie opisano zastosowanie ciagłej
˛ integracji z punktu widzenia praktycznego
– podajac
˛ i opisujac
˛ trzy przykłady narz˛edzi służacych
˛ do ciagłej
˛ integracji. Na koniec pod-
sumowano prac˛e przez podanie oceny przydatności ciagłej
˛ integracji w projektach informa-
tycznych.
Integracja w procesie produkcji oprogramowania
Poj˛ecia „integracji” czy „budowania” w kontekście procesu produkcji oprogramo-

wania odnosza˛ si˛e do szeregu czynności wykonywanych z kodem źródłowym aplikacji, zesta-
wem danych, zbiorem plików konfiguracyjnych i innymi informacjami wejściowymi, w celu
wyprodukowania aplikacji gotowej do użycia.
Należy podkreślić, że integracja nie jest równoważna z kompilacja.˛ Po pierwsze –
dlatego, że integracja może dotyczyć j˛ezyków (czy szerzej – technologii informatycznych),
w których nie ma potrzeby kompilacji. Po drugie – dlatego, że zakres poj˛ecia integracji może
zawierać kompilacj˛e, ale jest dużo szerszy – należy rozumieć przez to również scalanie kodu
źródłowego, wszelkiego rodzaju testowanie, instalowanie aplikacji na serwerze testowym itd.
Przebieg integracji zostanie omówiony szczegółowo w dalszej cz˛eści pracy.
Nazwa poj˛ecia integracji odnosi si˛e do scalania efektów pracy wykonanej niezależ-
nie przez poszczególnych członków zespołu – w tym łaczenia
˛ kodu źródłowego. Rozpoczy-
naja˛ oni swoja˛ prac˛e osobno, zwykle z tym samym kodem źródłowym. Nast˛epnie po jakimś
5 / 61
czasie (kilku godzinach, kilku dniach czy czasem tygodniach) zbieraja˛ si˛e i próbuja˛ dopaso-
wać swoje zmiany tak, by doprowadzić do poprawnego działania złaczonej
˛ aplikacji.
P. Duvall w [PD07] definiuje integracj˛e krótko jako:
działanie polegajace
˛ na połaczeniu
˛ oddzielnych elementów kodu źródłowego w ca-
łość w celu sprawdzenia, jak razem działaja.˛ 1
W projektach prowadzonych zgodnie z tradycyjnymi metodykami integracja jest

zwykle wydarzeniem majacymi
˛ miejsce pod koniec iteracji lub wr˛ecz całego projektu. W szcze-
gólności dopiero po zakończeniu albo pod koniec implementacji poszczególnych modułów
aplikacji rozpoczyna si˛e ich testowanie.
M. Fowler2 zauważa cz˛este kłopoty wynikajace
˛ z takiej organizacji pracy:
• Nigdy nie jest do końca wiadomo, jak długo taka integracja potrwa (co stanowi ogrom-
na˛ przeszkod˛e w planowaniu zasobów na potrzeby projektu informatycznego).
• Integracja jest długotrwałym procesem. W zależności od liczności zespołu, stopnia

pokrywania si˛e zakresów zadań i podobnych czynników czas potrzebny na integracj˛e
aplikacji wydłuża si˛e znacznie.
Dlatego sytuacja, w której integracja wykonywana jest raz na jakiś czas nazywana jest „inte-
gracyjnym piekłem” (ang. integration hell).
Odpowiedź na te bolaczki
˛ może stanowić ciagła
˛ integracja.
Ciagła
˛ integracja
Z poj˛eciem ciagłej
˛ integracji (ang. Continuous Integration) pierwszy raz można si˛e
było spotkać w pracach K. Becka i M. Fowlera – współautorów metodyki XP (od ang. Extre-
me Programming – programowanie ekstremalne).
Istota˛ pomysłu jest automatyzacja procesu integracji – tak, by mogła być wykony-
wana przez komputer, a nie człowieka (dzi˛eki czemu może być wykonywana cz˛eściej).
Sam M. Fowler definiuje w [Fow06] poj˛ecie ciagłej
˛ integracji jako:
1
Tłumaczenie własne. Podobnie wszystkie inne cytaty w pracy.
2
Martin Fowler - autor wielu ksia˛żek z dziedziny inżynierii oprogramowania, specjalizujacy
˛ si˛e w anali-
zie i projektowaniu zorientowanych obiektowo, j˛ezyku UML, wzorcach projektowych, zwinnych metodykach
prowadzenia projektów informatycznych (zwłaszcza Extreme Programming). Uznawany za pioniera ciagłej
˛ in-
tegracji.
6 / 61
praktyk˛e w projektach informatycznych polegajac

˛ a˛ na cz˛estym integrowaniu efek-
tów pracy przez członków zespołu. Zwykle każdy z nich integruje swoja˛ prac˛e co najmniej
raz dziennie, co skutkuje wieloma integracjami w ciagu
˛ dnia. Każda integracja jest spraw-
dzana przez automatyczny proces budowania (w tym testowanie) tak by wykrywać bł˛edy tak
szybko jak to jest możliwe.
Jest to w zasadzie najpopularniejsza definicja poj˛ecia, przyjmowana w miar˛e zgod-

nie przez wszystkich zaangażowanych w ruch ciagłej
˛ integracji. Nawet E. Minick w kry-
tycznym wobec tez M. Fowlera artykule3 definiuje poj˛ecie ciagłej
˛ integracji wzorujac
˛ si˛e na
powyższej definicji:
Ciagła
˛ integracja jest praktyka˛ w projektach informatycznych polegajac
˛ a˛ na cz˛estym
integrowaniu efektów pracy przez członków zespołu. Każda integracja jest sprawdzana przez
automatyczny proces testowania (w tym budowanie)4 tak, by wykrywać bł˛edy tak szybko jak
to jest możliwe.
Jak można zauważyć, choćby przygladaj

˛ ac ˛ si˛e sylwetkom twórców tego poj˛ecia, cia-
˛
gła integracja wywodzi si˛e z ruchu zwinnego oprogramowania. Nie widać jednak przeszkód
do zastosowania ciagłej
˛ integracji w projektach prowadzonych metodykami tradycyjnymi, co
również zostanie omówione w pracy.
Istot˛e ciagłej
˛ integracji można by zawrzeć w kilku punktach:
• opiera si˛e na zautomatyzowaniu procesu integracji aplikacji,
• jej wprowadzenie ma na celu przede wszystkim ułatwienie oceny i sama˛ popraw˛e ja-
kości wytwarzanego oprogramowania,
• wymaga poniesienia pewnych nakładów czy inwestycji organizacyjnych,
• nadaje si˛e do zastosowania w różnych projektach wytwarzania oprogramowania.

Powyższe punkty zostana˛ rozwini˛ete w dalszej cz˛eści pracy. W rozdziale 1 przed-
stawiono schemat działania serwerów ciagłej
˛ integracji, korzyści, jakie niesie ich wdrożenie,
oraz koszty, które należy przy tym ponieść. Rozdział 2 przedstawia praktyk˛e stosowania cia-
˛
głej integracji, opisujac
˛ popularne rozwiazania
˛ i najlepsze praktyki.
3
Patrz [Min08].
4
Na zamianie „testowania” i „budowania” E. Minick kładzie duży nacisk w swojej kontrpropozycji.
Wskazuje, że M. Fowler zaliczył testowanie jako jeden z etapów budowania. Sam uznaje budowanie (w tym
pewnie kompilacj˛e) jako po prostu jeden z wielu sposobów testowania aplikacji. Rzeczywiście nie sposób od-
mówić racji E. Minickowi w świetle roli ciagłej
˛ integracji w projekcie informatycznym.
7 / 61
Rozdział 1
Analiza środowisk ciagłej

˛ integracji
1.1 Schemat interakcji w środowisku ciagłej

˛ integracji
W każdym środowisku ciagłej
˛ integracji znaleźć można nast˛epujace
˛ elementy:
• użytkownicy – najcz˛eściej programiści, ale również inni współtworzacy

˛ produkt,
• repozytorium kodu – miejsce składowania kodu źródłowego aplikacji, system kontroli

wersji,
• serwer ciagłej
˛ integracji – narz˛edzie ciagłej
˛ integracji.
Użytkownicy pracuja˛ zwykle na swoich stacjach roboczych. Ich praca zaczyna si˛e
od pobrania kodu źródłowego z repozytorium kodu. Nast˛epnie dokonuja˛ zmiany kodu źró-
dłowego, testuja˛ zmieniany kod, po czym wgrywaja˛ poprawki do repozytorium.
Repozytorium kodu przechowuje kod źródłowy aplikacji we wszystkich historycz-
nych wersjach. W każdej chwili jest w stanie udost˛epnić zarówno najnowsza˛ wersj˛e kodu
źródłowego, jak i dowolne wcześniejsze wydanie. Poza kodem źródłowym aplikacji sensu
stricte repozytorium przechowuje wszystkie dane wejściowe potrzebne do zbudowania apli-
kacji.
Serwer ciagłej
˛ integracji jest narz˛edziem, które przeprowadza ciagł
˛ a˛ integracj˛e.
Regularnie, dla każdego zarzadzanego
˛ przez siebie projektu, pobiera najnowsza˛ wersj˛e kodu
źródłowego z repozytorium i dokonuje próby integracji. O wynikach próby informuje użyt-
kowników, udost˛epniajac
˛ raport z próby integracji.
Rysunek 1.1 w schematyczny sposób przedstawia proces ciagłej
˛ integracji i wymia-
n˛e informacji mi˛edzy trzema najważniejszymi elementami opisanymi powyżej.
8 / 61
Rysunek 1.1: Schemat interakcji w środowisku ciagłej

˛ integracji.
Źródło: Opracowanie własne.
Najcz˛eściej w danej organizacji rozwija si˛e wi˛ecej niż jeden projekt. Każdy z nich
z osobna konfiguruje si˛e w taki sposób, by był zarzadzany
˛ przez serwer ciagłej
˛ integracji. Tak
wi˛ec serwer ciagłej
˛ integracji zwykle nadzoruje integracj˛e wi˛ecej niż jednego projektu.
Co wi˛ecej, czasami dany projekt wyst˛epuje w różnych wersjach i równolegle trwaja˛
prace programistyczne nad różnymi wersjami tego samego projektu. Zasadnym jest potrak-
towanie wtedy różnych wersji jako osobnych projektów z punktu widzenia ciagłej
˛ integracji
– wszak różni si˛e ich baza kodu źródłowego, wymagania przed nimi stawiane itd.
Stan projektu – poprawny czy niepoprawny – jednoznacznie określany jest przez
ostatnia˛ prób˛e integracji. Jeśli si˛e powiodła (tj. aplikacja przeszła pomyślnie proces budowa-
nia, wszystkie sprawdzenia), uznaje si˛e, że projekt w systemie ciagłej
˛ integracji jest w stanie
poprawnym. Jeśli ostatnia próba integracji z jakichkolwiek powodów si˛e nie powiodła, okre-
śla si˛e stan jako niepoprawny. Warto podkreślić, że wcześniejsze niż ostatnie wyniki integra-
cji nie maja˛ znaczenia dla określenia stanu projektu. Nawet jeśli projekt przez ostatni tydzień
integrował si˛e poprawnie, a jedna ostatnia integracja si˛e nie powiodła - mówi si˛e, że projekt
9 / 61
jest w stanie niepoprawnym. Oczywiście nie wyklucza to sensowności badania historii inte-
gracji i zliczania, jak cz˛esto projekt wyst˛epuje w stanie poprawnym. Nie należy jednak mylić
tego ze stanem projektu.
Wyzwalanie integracji
Istnieja˛ co najmniej dwa główne podejścia do tego, kiedy serwer ciagłej

˛ integracji
ma dokonywać próby integracji:
• Według harmonogramu. W najprostszym podejściu dla każdego z projektów zarza-

˛
dzanych przez serwer ciagłej
˛ integracji ustala si˛e odst˛ep czasu mi˛edzy próbami integra-
cji. W bardziej złożonych ustawieniach precyzyjnie definiuje si˛e momenty w każdym
tygodniu czy każdym dniu, w których ma nastapić
˛ próba integracji - np. co godzin˛e od
poniedziałku do piatku
˛ od godziny 8 do 18.
W środowiskach, w których zarzadza
˛ si˛e kilkoma czy kilkunastoma projektami, odst˛ep
mi˛edzy poszczególnymi próbami integracji ustawia si˛e na czas rz˛edu minut – od kil-
kunastu do kilkudziesi˛eciu. W wi˛ekszych instalacjach ze wzgl˛edów wydajnościowych
jest to odst˛ep rz˛edu godzin (jeśli jest to jeszcze dłuższy odst˛ep - np. rz˛edu dni, trudno
już mówić o ciagłej
˛ integracji).
• Przy każdej zmianie kodu w repozytorium. W tym podejściu podczas wgrywania

przez programist˛e zmian w kodzie do repozytorium nast˛epuje próba integracji. Kod
pozostaje nie w pełni zatwierdzony, dopóki nie dokona si˛e całość integracji. Jeśli pró-
ba skończy si˛e pomyślnie, kod jest zatwierdzany; w przeciwnym przypadku jest od-
rzucany. Do skonfigurowania takiego zachowania potrzebne jest wsparcie ze strony
repozytorium kodu (nie wszystkie popularne repozytoria kodu udost˛epniaja˛ taka˛ moż-
liwość).
Co najważniejsze, rozwiazanie
˛ to gwarantuje, że ani przez chwil˛e repozytorium nie
przechowuje wadliwego kodu. Jednak jest trudniejsze do zastosowania ze wzgl˛edów
organizacyjnych. Wymaga ono, by proces integracji był bardzo szybki, co kłóci si˛e
z idea˛ dokładnego testowania, które siła˛ rzeczy musi być czasochłonne.
Wi˛ekszość serwerów ciagłej

˛ integracji umożliwia ustawienie integracji według har-
monogramu; niektóre bardziej zaawansowane pozwalaja˛ również na automatyczne dokony-
wanie integracji przy każdej zmianie w repozytorium.
10 / 61
Dodatkowo serwery ciagłej

˛ integracji umożliwiaja˛ r˛eczne wyzwolenie próby inte-
gracji niezależnej od automatycznych ustawień. Zwykle taka opcja jest dost˛epna z poziomu
interfejsu użytkownika serwera ciagłej
˛ integracji.
1.2 Warunki zastosowania ciagłej

˛ integracji
Jak już wcześniej zauważono, sama idea ciagłej
˛ integracji wywodzi si˛e z metodyk
zwinnych. Nic dziwnego, że znajduje zastosowanie w projektach informatycznych prowa-
dzonych według nich. W podejściu tradycyjnym stawia si˛e jakieś cele wobec aplikacji i do-
piero pod koniec czasu zarezerwowanego na projekt wymaga si˛e działajacej
˛ aplikacji (nawet
w przypadku podziału prac nad aplikacja˛ na kamienie milowe nie zawsze wymaga si˛e, by na
półmetku aplikacja była w stanie działajacym
˛ i gotowa do użycia). Jedna˛ z fundamentalnych
cech, które odróżniaja˛ metodyki zwinne od tradycyjnych jest nieustanne tworzenie funkcjo-
nalnego oprogramowania. Przekłada si˛e to na wymaganie, by możliwie najcz˛eściej aplikacja
była w poprawnym stanie. Oczekuje si˛e, że w każdej chwili b˛edzie można z niej skorzystać –
nawet jeśli zakres dotychczas zaimplementowanej funkcjonalności jest bardzo ograniczony.
Ciagła
˛ integracja jest koncepcja,˛ która w pewien sposób nadzoruje realizacj˛e tego
postanowienia. W sposób ciagły
˛ bada si˛e stan aplikacji, co w naturalny sposób tworzy presj˛e,
by ten stan był poprawny możliwie jak najcz˛eściej. Długie pozostawanie aplikacji prowadzo-
nej metodyka˛ zwinna˛ w stanie niepoprawnym z pewnościa˛ świadczy o nieprawidłowościach
i jest sytuacja˛ niepożadan
˛ a.˛
Z drugiej strony nie widać żadnego powodu, dla którego nie można by stosować
ciagłej
˛ integracji również w projektach prowadzonych metodykami tradycyjnymi czy zarza-
˛
dzanych w autorski sposób. Ciagła
˛ integracja może wtedy stanowić dodatkowe narz˛edzie
kontroli jakości, raportowania stanu rozwoju aplikacji i śledzenia zmian.
Innym ciekawym pomysłem jest potencjalne zastosowanie ciagłej
˛ integracji przy
produkcji produktów nieb˛edacych
˛ oprogramowaniem – zwłaszcza w dzisiejszych czasach,
kiedy komputery sa˛ narz˛edziami używanymi w najróżniejszych dziedzinach ludzkiej aktyw-
ności. Naturalnie nie wszystkie pomysły, które niesie ciagła
˛ integracja, da si˛e zastosować
w dziedzinach innych niż tworzenie oprogramowania. Niemniej z pewnościa˛ da si˛e wyko-
rzystać same narz˛edzia ciagłej
˛ integracji i cz˛eść ogólnych koncepcji. Jako przykład może
posłużyć zaprz˛egni˛ecie ciagłej
˛ integracji do tworzenia i redagowania publikacji tekstowych
z wykorzystaniem systemów automatycznego składu tekstu. Podsumowujac,
˛ ciagła
˛ integra-
cja mogłaby znaleźć zastosowanie wsz˛edzie tam, gdzie proces tworzenia wymaga twórczej
11 / 61
pracy ludzi, która nast˛epnie może być w sposób zautomatyzowany przetwarzana w celu uj-
rzenia końcowego produktu.
Nie widać ważnych czynników ograniczajacych
˛ sensowność stosowania ciagłej
˛ in-
tegracji w zależności od wielkości zespołu programistycznego. Ciagła
˛ integracja ma nawet
pewien sens w projektach jednoosobowych, oczywiście dużo wi˛ekszy – w liczniejszych
przedsi˛ewzi˛eciach. Po przekroczeniu pewnej skali (kilku – kilkunastu osób) ciagła
˛ integracja
wymaga pewnego sformalizowania ról – mianowania osób odpowiedzialnych za integracj˛e
poszczególnych projektów (podobnie bez stosowania ciagłej
˛ integracji taki rozmiar zespołu
programistycznego wymaga pewnej struktury. Tak wi˛ec w pewien sposób ciagła
˛ integracja
nie narzuca tym samym nowego wymagania). Najpewniej do zadań osoby odpowiedzialnej
za integracj˛e projektu trzeba by zaliczyć na przykład:
• monitorowanie stanu aplikacji i reagowanie na dłuższe pozostawanie aplikacji w stanie

niepoprawnym,
• przydzielanie poszczególnym członkom zespołu zadań naprawy bł˛edów wykrytych

przez serwer ciagłej
˛ integracji,
• rozwiazywanie
˛ wszelkich problemów ze środowiskiem używanym przez serwer ciagłej
˛
integracji do budowania projektu.
Szczegółowy zakres zadań osoby nadzorujacej

˛ integracj˛e jest uzależniony od specy-
fiki konkretnego projektu i organizacji pracy w danym zespole.
1.3 Możliwości środowisk ciagłej

˛ integracji
Aby poznać możliwości środowisk ciagłej
˛ integracji warto prześledzić kolejne fazy
integrowania aplikacji. W integracji przebiegajacej
˛ automatycznie, a wi˛ec i w konfiguracji
serwera ciagłej
˛ integracji uwzgl˛ednia si˛e najcz˛eściej nast˛epujace
˛ etapy (w kolejności ich ty-
powego wyst˛epowania):
• odświeżanie kodu źródłowego i innych danych wejściowych integracji,
• podj˛ecie decyzji o zasadności kontynuowania integracji,
• budowanie,
• testowanie i mierzenie stopnia pokrycia kodu testami,
12 / 61
• statyczna analiza kodu i automatyczny przeglad

˛ kodu,
• umieszczenie i uruchomienie (ang. deployment) aplikacji w środowisku testowym,
• testowanie aplikacji uruchomionej w środowisku testowym,
• zapisanie wyniku integracji i powiadomienie o nim użytkowników,
• (w przypadku pomyślnego przejścia poprzednich wszystkich kroków) oznaczenie kodu

źródłowego jako działajacego
˛ oraz zachowanie i udost˛epnienie zbudowanej aplikacji.
Oczywiście nie jest to lista wyczerpujaca.

˛ W szczególności, zależnie od specyfiki
projektu (zastosowanych w nim technologii, produktów, które ma dostarczyć, i dużej liczby
innych ważnych czynników) za każdym razem przy definiowaniu procesu ciagłej
˛ integracji
uwzgl˛ednia si˛e różne etapy integracji. Powyższa˛ list˛e należy traktować jedynie jako ogólny
przykład definicji procesu integracji. Dla bardziej czytelnego zaprezentowania procesu inte-
gracji aplikacji powyższe etapy przedstawiono graficznie na rysunku 1.2.
Ogólna˛ zasada˛ przetwarzania w procesie integracji jest przerywanie przy pierwszym
napotkanym bł˛edzie (czerwone strzałki na rysunku 1.2). Tzn. jeśli w którymkolwiek etapie
nastapi
˛ bład,
˛ cała integracja jest przerywana, a jej wynik zostaje odnotowany jako negatywny.
Naturalnie podczas próby integracji moga˛ wystapić
˛ różnego rodzaju bł˛edy – dotyczace
˛ za-
równo samej aplikacji, jak i infrastruktury budowania. Na przykład podczas kompilacji może
wystapić
˛ bład˛ spowodowany nie tylko niepoprawnym składniowo kodem źródłem, ale także
brakiem wolnej pami˛eci operacyjnej5 . Serwer ciagłej
˛ integracji zwykle nie rozróżnia mi˛edzy
typami bł˛edów i reaguje identycznie – zgłasza niepowodzenie i zapisuje komunikat bł˛edu.
Z kolei integracja zakończona sukcesem ma miejsce wtedy, gdy wszystkie kroki
integracji zostana˛ wykonane bez napotkania żadnego bł˛edu (zielone strzałki na rysunku 1.2).
Poszczególne etapy integracji zostały opisane w nast˛epnych podrozdziałach.
Warto w tym miejscu zaznaczyć, że proces integracji dostarcza wielu produktów,
oczym mówi rozdział 1.4.
5
Niepowodzenie kompilacji (czy któregokolwiek innego etapu integracji) z powodu braku wolnej pami˛eci
operacyjnej czy miejsca na dysku może stanowić dobry przykład niedeterminizmu integracji. Tzn. dwie próby
integracji z tymi samymi danymi (z tym stanem repozytorium) moga˛ dać zupełnie różne wyniki.
13 / 61
Rysunek 1.2: Przykładowy przebieg integracji.

14 / 61
1.3.1 Odświeżanie kodu źródłowego
Pierwszym etapem każdej integracji jest odświeżenie kodu źródłowego. Jest to etap
o tyle konieczny, że do dalszych kroków integracji potrzebne sa˛ dane wejściowe. Głównym
ich elementem jest kod źródłowy aplikacji; dodatkowymi elementami moga˛ być różnego
rodzaju pliki konfiguracyjne, skrypty bazodanowe itp. Samo odświeżenie kodu źródłowego
i danych polega na wykonaniu operacji pobrania najnowszej wersji plików z repozytorium
kodu. Ze wzgl˛edu na różnorodność repozytoriów kodu serwery ciagłej
˛ integracji dostarczaja˛
zwykle osobne interfejsy do każdego z nich.
W tym miejscu warto podkreślić konieczność przechowywania przez repozytorium
całości kodu źródłowego, plików konfiguracyjnych, skryptów bazodanowych i wszystkich
innych zasobów potrzebnych do integracji i uruchomienia aplikacji. Chociaż ten wymóg wy-
daje si˛e być banalny i oczywisty, to jednak cz˛esto spotyka si˛e organizacje, w których w wy-
niku bałaganu, niefrasobliwości czy braku dobrze określonych procedur, niektóre dane nie sa˛
przechowywane w repozytorium kodu (np. minimalna zawartość bazy danych potrzebna do
uruchomienia aplikacji) – patrz rozdział 2.2.
1.3.2 Decyzja o zasadności kontynuowania integracji
Kontynuowanie integracji nie zawsze jest celowe. Jako przykład niech posłuża˛ dwie
typowe sytuacje.
Po pierwsze, po odświeżeniu kodu z repozytorium może si˛e okazać, że od czasu
ostatniej próby integracji aplikacji nie nastapiły
˛ żadne zmiany w kodzie źródłowym (czy
ogólniej – w zbiorze danych wejściowych integracji). Cz˛esto serwery ciagłej
˛ integracji kon-
figuruje si˛e w ten sposób by nie podejmować w takiej sytuacji kolejnej próby integracji. Jako
że proces integracji powinien być deterministyczny, wi˛ec kolejna integracja z tymi samymi
danymi wejściowymi powinna dać ten sam wynik. Jak wykazano powyżej, ze wzgl˛edu na
sama˛ zmienność środowiska, w którym dokonuje si˛e ciagła
˛ integracja, takie założenie nie
musi być słuszne.
Po drugie, cz˛estokroć jedna organizacja rozwija kilka różnych projektów zależnych
od siebie – aplikacje dzielone sa˛ na moduły badź
˛ jedne aplikacje wymagaja˛ innych aplika-
cji do działania. W szczególności czasami do integracji aplikacji nadrz˛ednej konieczne sa˛
uprzednio zbudowane wersje aplikacji zależnych. Dlatego jeśli ostatnia próba integracji jed-
nej z zależnych aplikacji zakończyła si˛e fiaskiem, nie ma sensu przeprowadzać integracji
aplikacji nadrz˛ednej.
15 / 61
Jak wynika z powyższych przykładów, cz˛esto konfiguruje si˛e serwer ciagłej

˛ integra-
cji w taki sposób, że nie podejmuje próby integracji w sytuacji, kiedy jej wynik jest z góry
możliwy do przewidzenia. Wynika to zwykle z ch˛eci zaoszcz˛edzenia zasobów – głównie
czasu obliczeniowego serwera ciagłej
˛ integracji, który może być spożytkowany na integracj˛e
innych projektów.
1.3.3 Budowanie
Budowanie jest najistotniejszym etapem integracji, w ogólności ma na celu prze-
transformowanie kodu źródłowego aplikacji do takiej postaci, która˛ da si˛e uruchomić. W za-
leżności od konstrukcji technologicznej aplikacji (w tym j˛ezyka programowania, infrastruk-
tury) proces budowania może przybierać różne kształty.
W niektórych technologiach proces budowania jest na tyle skomplikowany, że wy-
maga wykorzystania specjalnie do tego celu przeznaczonych narz˛edzi. Serwery ciagłej
˛ inte-
gracji nie zajmuja˛ si˛e bowiem samym budowaniem, a raczej jedynie uruchamianiem odpo-
wiednio skonfigurowanego narz˛edzia budujacego.
˛
Przykład 1. W technologii JEE proces budowania najcz˛eściej ma na celu wypro-

dukowanie pliku EAR. Cz˛esto wykorzystuje si˛e do tego narz˛edzie Apache Ant, które – od-
powiednio skonfigurowane – kompiluje kod źródłowy, pakuje skompilowane klasy, dołacza
˛
inne zasoby i pakuje plik EAR. W skład konfiguracji serwera ciagłej
˛ integracji wchodzi wte-
dy tylko uruchomienie narz˛edzia Ant z odpowiednim plikiem konfiguracyjnym.
Przykład 2. Jako inny przykład można podać aplikacj˛e uruchamiana˛ jako program
wykonywalny w systemie Linux. Głównym produktem integracji może być w takim przy-
padku pakiet programu (typu RPM, DEB, itp.), którego stworzenie zdefiniowane jest w pliku
konfiguracyjnym narz˛edzia budujacego
˛ pakiety – np. poprzez kompilacj˛e kodu źródłowego
i linkowanie.
Przykład 3. Z kolei proces budowania w projekcie biblioteki komponentów wizu-

alnych zaimplementowanej w j˛ezyku JavaScript b˛edzie najpewniej stosunkowo prosty. Jako
że j˛ezyk JavaScript jest j˛ezykiem interpretowanym, a nie kompilowanym, budowanie takiej
aplikacji mogłoby być zdefiniowane jako spakowanie plików w jedno archiwum ZIP czy tak
zwana minimalizacja skryptów JavaScript (konwersja kodu źródłowego do równoważnego
dla komputera kodu, ale zapisanego z użyciem mniejszej liczby znaków).
16 / 61
Podsumowujac:
˛ produktem budowania powinna być aplikacja w postaci gotowej do
uruchomienia – czy to w postaci jednego pliku, czy zestawu plików.
1.3.4 Testowanie
Jak podkreślono we wst˛epie tej pracy, jednym z głównych celów wdrożenia cia-
˛
głej integracji jest poprawa jakości wytwarzanego oprogramowania. Podstawowymi narz˛e-
dziami mierzacym
˛ jakość oprogramowania sa˛ różnorakie testy. Opis możliwych podejść do
testowania aplikacji leży poza zakresem tej pracy, warto jednak podkreślić, że z natury rze-
czy środowiska ciagłej
˛ integracji współpracuja˛ dobrze jedynie z paradygmatami testowania
umożliwiajacymi
˛ automatyzacj˛e procesu testowania.
W konsekwencji wszelkie scenariusze r˛ecznych testów nie znajduja˛ zastosowania

w środowiskach ciagłej
˛ integracji. Powoduje to, że zespoły programistyczne wdrażajace
˛ po-
dejście ciagłej
˛ integracji, zmuszone sa˛ do poszukiwania i wykorzystywania zautomatyzowa-
nych środowisk testowych. Bez watpienia
˛ stanowi to pewien koszt, ale przynosi również duże
korzyści – o czym mowa w dalszych rozdziałach 1.5 i 1.6.
Ze wzgl˛edu na powyższe uwarunkowania automatyczne testy aplikacji powinny sta-

nowić kluczowy etap procesu integracji. Sa˛ one miernikiem jakości oprogramowania i po-
zwalaja˛ śledzić wpływ ostatnich zmian w kodzie źródłowym na poprawność aplikacji.
Wszelkie testy niewymagajace

˛ uruchomienia aplikacji w pełnym środowisku, takie
jak testy jednostkowe, warto wydzielić do osobnego kroku integracji. Pozwala to wykonać
je przed pełnym budowaniem i instalowaniem aplikacji, co z kolei umożliwia wcześniejsze
wykrycie ewentualnych bł˛edów (i tym samym zalicza si˛e do zysków z wprowadzenia ciagłej
˛
integracji – patrz rozdział 1.5).
Produktem testowania jest raport z testów. Wi˛ekszość narz˛edzi automatycznego te-

stowania dostarcza automatycznie spreparowany plik b˛edacy
˛ podsumowaniem przeprowa-
dzonych testów – z informacja,˛ jakie testy zostały uruchomione, ile trwały, jaki był ich wynik,
ile testów zakończyło si˛e pomyślnie, a ile porażka,˛ itp. Rysunek 1.3 przedstawia przykładowy
raport z testów narz˛edzia JUnit.
17 / 61
Rysunek 1.3: Przykładowy raport z testów narz˛edzia JUnit.

Źródło: http://cagrid.org/display/gme13/Design+Guide.
Testy interfejsu użytkownika stanowia˛ na tyle ważny aspekt testowania, że warto im
si˛e dokładnie przyjrzeć; z tego powodu zostały wydzielone z niniejszego opisu do osobnego
podrozdziału – 1.3.7.
Pokrycie kodu testami
Warto zauważyć, że sam wynik przeprowadzenia zestawu testów (zarówno pojmo-
wany w prosty sposób: jako negatywny lub pozytywny, jak i dokładniejszy – liczba niedzia-
łajacych
˛ testów) nie musi być jedynym efektem testowania.
Przydatne informacje daja˛ narz˛edzia do mierzenia pokrycia kodu źródłowego te-
stami. Dzi˛eki zastosowaniu różnych technik systemowych można mierzyć dokładnie, które
linie kodu aplikacji zostały wykonane podczas uruchomienia testów. Pozwala to określić
tzw. stopień pokrycia kodu testami, co już jako pojedyncza liczba może świadczyć o stopniu
przetestowania aplikacji. Im wi˛eksza cz˛eść kodu źródłowego jest przetestowana przez te-
sty jednostkowe, tym pewniejszy jest sam wynik testów. Ideałem byłoby oczywiście, gdyby
wskaźnik pokrycia kodu testami był bliski 100%, jednak osiagni˛
˛ ecie takiego wyniku może
być kosztowne. Samo rozłożenie wagi mi˛edzy ilościa˛ nakładów na tworzenie testów a wiel-
kościa˛ wskaźnika (przekładajacego
˛ si˛e na wiarygodność testów) pozostawia si˛e do decyzji
osób zarzadzaj
˛ acych
˛ projektem.
Co ważne, jeśli w danym projekcie wskaźnik pokrycia kodu testami jest stosunkowo
wysoki, pozwala to być pewniejszym jakości produktów. Równie ważna˛ wiadomość stanowi
18 / 61
niewielka wartość tego wskaźnika – informuje o niepewności testów, co z punktu widzenia

biznesowego można odbierać jako niepewność co do jakości aplikacji.
Przykład raportu narz˛edzia mierzacego
˛ pokrycie kodu testami można zobaczyć na
poniższym rysunku.
Rysunek 1.4: Przykład raportu pokrycia kodu testami wygenerowanego przez narz˛edzie
Clover firmy Atlassian.
Źródło: http://www.atlassian.com/software/clover/screenshots/.
Najważniejsza informacja w powyższym widoku to współczynnik pokrycia wyno-

szacy
˛ 82,6%. Ponadto prezentowane sa˛ mi˛edzy innymi:
• histogram współczynnika pokrycia kodu poszczególnych klas,
• wykres zależności mi˛edzy złożonościa˛ klasy a pokryciem testami,
• diagram najbardziej złożonych pakietów i ich współczynników pokrycia,
• 100% pozytywny wynik wykonanych testów,
• klasy, które według jakiejś heurystyki sa˛ wskazane jako 20 najbardziej niepewnych
(można podejrzewać, że narz˛edzie wybiera najbardziej złożone klasy z najmniejszym
pokryciem testami),
• list˛e najmniej przetestowanych metod.
19 / 61
Narz˛edzia mierzace
˛ pokrycie testami udost˛epniaja˛ też dużo dokładniejsze statysty-
ki. Niektóre z nich podaja˛ dla każdej linii kodu wartość pokazujac
˛ a,˛ ile razy dana linia zosta-
ła uruchomiona podczas testów. Ułatwia to programistom tworzenie przekrojowych testów
sprawdzajacych
˛ różne przebiegi działania aplikacji, a wi˛ec w końcowym efekcie przyczynia
si˛e do zwi˛ekszenia świadomości na temat jej faktycznej jakości.
Jest to o tyle ważne, że niedoświadczeni autorzy testów cz˛esto maja˛ tendencj˛e do
sprawdzania tylko tzw. przebiegów pozytywnych. Oznacza to, że nie testuja,˛ jak aplikacja
reaguje na różnego rodzaju bł˛edy, niepoprawne dane wejściowe czy inne niepożadane
˛ badź
˛
nietypowe sytuacje. W takich przypadkach narz˛edzie mierzace
˛ pokrycie kodu testami cz˛esto
wykazuje, że te partie kodu, które zajmuja˛ si˛e obsługa˛ bł˛edów czy sytuacji wyjatkowych,
˛ nie
zostały w ogóle przetestowane. Okazuje si˛e to jednak na tyle wcześnie, że można jeszcze
nadrobić te braki. Widać wi˛ec, że wyniki takiej analizy sa˛ dla autorów testów bardzo cenne.
Rysunek 1.5: Wycinek raportu narz˛edzia Clover opisujacy

˛ pokrycie testami poszczególnych
linii kodu źródłowego.
Źródło: http://www.atlassian.com/software/clover/sample-reports.
jsp.
Przykład 4. Na powyższym rysunku przedstawiono szczegółowy raport narz˛edzia

Clover przedstawiajacy
˛ fragment kodu źródłowego od linii 453 do 472 pewnej klasy. Na
marginesie każdej z niepustych linii wskazano, ile razy dana instrukcja została wykonana
podczas uruchomienia testów. Przykładowo, instrukcja warunkowa w linii 459 została wy-
konana 11200 razy, ale tylko 6261 została wyliczona pozytywnie, bo instrukcja w linii 460
wykonana została tyle razy.
20 / 61
Ciekawy jest przykład kolejnej instrukcji warunkowej w linii 464. Liczba na marginesie
wskazuje, że instrukcja została wykonana 11200 razy, ale czerwony kolor tła informuje, że
za każdym razem wyliczenie dało ten sam wynik. Za każdym razem z tych 11200 razy stero-
wanie przechodziło do linii 465, co świadczy o tym, że ani razu nie został przetestowany ten
fragment kodu z danymi powodujacymi
˛ negatywne wyliczenie warunki instrukcji warunko-
wej. Najlepiej by było dopisać nowy test, który skutkuje uruchomieniem tego samego kodu,
podczas którego wyrażenie e.parent b˛edzie miało wartość null.
1.3.5 Przeglad
˛ kodu – statyczna analiza kodu
Testy aplikacji – czy to jednostkowe, czy integracyjne – uruchamiaja˛ mniejsze lub

wi˛eksze fragmenty kodu i sprawdzaja˛ efekty tego działania. Nie jest to jednak jedyny sposób
badania jakości kodu źródłowego – można to również robić w sposób statyczny (tj. bez jego
uruchamiania). Statyczna analiza kodu jest najlepszym przykładem automatycznego przegla-
˛
du kodu6 .
Na rynku dost˛epnych jest wiele narz˛edzi do statycznej analizy kodu. Kryteria stoso-
wane przez nie podczas oceny kodu sa˛ różne.
Niektóre narz˛edzia potrafia˛ wyszukiwać podejrzane zapisy w kodzie źródłowym.

Oczywiście komputery (przynajmniej obecnie) nie potrafia˛ ocenić, czy dany kod źródłowy
jest poprawny – dlatego, że zwykle specyfikacja nie jest wyrażana w jednoznacznym j˛ezy-
ku rozumianym przez komputery. Nie moga˛ one zatem jednoznacznie stwierdzić, czy dany
kod jest poprawna˛ implementacja˛ danej specyfikacji. Niemniej istnieja˛ pewne dobre i złe
praktyki programowania, a kod poprawny w sensie składniowym danego j˛ezyka może być
niepoprawny z innych wzgl˛edów. Aby wspomóc identyfikacj˛e takich niepoprawnych zapi-
sów, stworzono narz˛edzia, które wskazuja˛ tzw. brzydkie zapachy (ang. code smells) w kodzie,
sygnalizujac
˛ potencjalne kłopoty. Sposób działania tych narz˛edzi oparty jest na analizie ty-
powych bł˛edów popełnianych przez programistów.
6
Poj˛ecie przegladu
˛ kodu zwykle rozumie si˛e jako r˛eczne przejrzenie zmian w kodzie innego członka ze-
społu programistycznego w celu wykrycia bł˛edów, usterek czy niezgodności ze specyfikacja.˛ Poj˛ecie automa-
tycznego przegladu
˛ kodu nawiazuje
˛ do tego, niejako podkreślajac
˛ podobny cel obu procesów, mimo stosowania
zupełnie różnych środków.
21 / 61
Rysunek 1.6 przedstawia wycinek przykładowego raportu narz˛edzia FindBugs7 . Każ-

dy typ bł˛edu ma swoje krótkie oznaczenie (np. IL) oraz dłuższy opis po angielsku wyjaśnia-
jacy
˛ istot˛e problemu. Wszystkie wystapienia
˛ bł˛edów sa˛ wskazane przez podanie nazwy pliku
i numeru linii, w której usterka wyst˛epuje. Nie wszystkie z bł˛edów wskazywanych przez
to narz˛edzie sa˛ oczywiste na pierwszy rzut oka. Dlatego pomocna˛ może si˛e okazać stro-
na domowa projektu8 , która zawiera dokładniejsze informacje o przyczynie zaszeregowania
danych konstrukcji programistycznych do kategorii bł˛edów i skutkach ich użycia w kodzie
tworzonych aplikacji.
Rysunek 1.6: Wycinek raportu narz˛edzia FindBugs.

Źródło: http://findbugs.sourceforge.net/commons-modeler.html.
Innym przykładem tego typu narz˛edzi sa˛ programy sprawdzajace

˛ zgodność zapisu
kodu źródłowego z zasadami formatowania kodu. Niektóre firmy maja˛ ustalone odgórnie for-
malne dokumenty określajace
˛ sposób zapisu kodu źródłowego tworzonych aplikacji. W in-
nych organizacjach spotyka si˛e oddolna˛ inicjatyw˛e majac
˛ a˛ na celu uwspólnienie pewnych
przyzwyczajeń.
7
Aplikacja FindBugs została stworzona na amerykańskim Uniwersytecie Maryland i jest bezpłatnie roz-
powszechniana na licencji LGPL.
8
http://findbugs.sourceforge.net/.
22 / 61
Oczywiście takie elementy jak wielkość zastosowanych wci˛eć, sposób pisania ko-
mentarzy, nazewnictwo klas, metod, funkcji czy zmiennych, nie wpływaja˛ na jakość działania
samej aplikacji (można powiedzieć – sa˛ oboj˛etne komputerowi), jednak mimo wszystko sa˛
to ważne cechy kodu, bo nie sa˛ one oboj˛etne ludziom – tym, którzy ten kod źródłowy b˛eda˛
utrzymywać, poprawiać, testować itd.
Przykładowym narz˛edziem sprawdzajacym
˛ formatowanie kodu źródłowego w sto-
sunku do ustalonych reguł jest Checkstyle9 . Podobnie jak FindBugs narz˛edzie wyszczególnia
linie kodu źródłowego, w których wyst˛epuja˛ bł˛edy, wskazujac
˛ ich wady. Ponadto wszystkie
usterki sa˛ podzielone na priorytety – w zależności od stopnia rozbieżności kodu z wytyczny-
mi.
Rysunek 1.7: Wycinek przykładowego raportu narz˛edzia Checkstyle.

Źródło: http://maven.apache.org/plugins/maven-checkstyle-plugin/
checkstyle.html.
Jednym z etapów automatycznej integracji może być zatem uruchomienie narz˛edzi

statycznej analizy kodu, które wskaża˛ usterki w kodzie. W zależności od konfiguracji wykry-
cie usterek pewnej określonej klasy może nawet przerywać ze skutkiem negatywnym proces
integracji. W tym zakresie decyzja nie jest jednoznaczna i zależy od zasad ustalonych w danej
organizacji czy danym projekcie informatycznym.
9
Darmowe narz˛edzie rozpowszechniane na licencji LGPL. Patrz http://checkstyle.
sourceforge.net/.
23 / 61
1.3.6 Uruchomienie aplikacji
Jednym z najważniejszych etapów integracji aplikacji jest jej uruchomienie. Jest

to o tyle ważny krok, ponieważ daje odpowiedź, czy aplikacja jako taka działa. Nie jest
sprawdzane funkcjonowanie poszczególnych modułów aplikacji, ale samo jej uruchomienie.
Wbrew pozorom dosyć cz˛esto si˛e zdarza, że podczas inicjacji aplikacji wyst˛epuja˛ bł˛edy. Tym
ważniejsze by proces ciagłej
˛ integracji poinformował o pojawieniu si˛e takich usterek możli-
wie jak najszybciej.
Ogólny kształt procesu uruchomienia aplikacji przez serwer ciagłej
˛ integracji przed-
stawia rysunek 1.8.
Rysunek 1.8: Przebieg procesu uruchomienia aplikacji przez serwer ciagłej

˛ integracji.
W zależności od technologii uruchomienie aplikacji może być prostszym lub trud-

niejszym procesem. Zwłaszcza w tym drugim przypadku zasadnym wydaje si˛e zautomatyzo-
wanie tego kroku i właczenie
˛ go do ciagu
˛ operacji automatycznej integracji.
Krok ten ma na celu sprawdzenie, czy świeżo zbudowana wersja aplikacji daje si˛e
poprawnie uruchomić. Cz˛esto bł˛edy programistów skutkuja˛ tym, że aplikacja si˛e w ogóle nie
uruchamia – a to z kolei da si˛e w miar˛e prosto wykryć w automatyczny sposób.
24 / 61
Przykład 5. W przypadku aplikacji dost˛epnych przez przegladark˛

˛ e WWW do
sprawdzenia, czy aplikacja została uruchomiona poprawnie i czy strona główna aplikacji
ładuje si˛e bez bł˛edów, wystarczy prosty klient HTTP.
Należy pami˛etać, że w wi˛ekszości obecnie rozwijanych aplikacji istotnym elemen-

tem jest baza danych. W skład procesu uruchomienia aplikacji należy wi˛ec zaliczyć urucho-
mienie i załadowanie danych do bazy danych, co z kolei podkreśla wag˛e konieczności prze-
chowywania również schematu i zawartości bazy danych w postaci skryptów potrafiacych
˛
ja˛ zakładać. Przeciwna˛ strategia˛ jest utrzymywanie działajacej
˛ bazy danych i traktowanie jej
schematu i zawartości jako definicji kształtu bazy danych wymaganej przez aplikacj˛e. Takie
podejście ma jednakże dwie zasadnicze wady:
• Nie jest przenośne – tj. w przypadku konieczności założenia nowej instancji bazy da-
nych na innym serwerze wymaga dodatkowego nakładu, którego da si˛e uniknać
˛ prze-
chowujac
˛ skrypty tworzace
˛ baz˛e danych.
• Baza danych ma ograniczone zastosowanie w porównaniu ze skryptami. Skrypty ba-

zodanowe nie musza˛ służyć do zakładania bazy danych dla aplikacji – moga˛ służyć
do zakładania bazy danych tworzonej w pami˛eci na potrzeby testów, czy do różnego
rodzaju tekstowego przetwarzania.
Oczywiście bład
˛ podczas automatycznego uruchomienia aplikacji definitywnie dys-
kwalifikuje dana˛ wersj˛e aplikacji. Skutkiem tego powinno nastapić
˛ przerwanie próby inte-
gracji z wynikiem negatywnym. Z drugiej strony samo poprawne uruchomienie aplikacji nie
jest jeszcze gwarancja˛ jej poprawnego działania, dlatego warto to działanie przetestować –
o czym mowa w nast˛epnym podrozdziale.
1.3.7 Testowanie interfejsu aplikacji

W klasycznym podejściu do testowania aplikacji przygotowuje si˛e scenariusze te-
stów. Taki scenariusz jest zapisem interakcji użytkownika z aplikacja˛ – naprzemiennie wypi-
suje si˛e akcje użytkownika i spodziewana˛ reakcj˛e aplikacji. Jak podkreślono w podrozdzia-
le 1.3.4, r˛eczne testy nie nadaja˛ si˛e do wplecenia ich w proces automatycznej integracji. Nie
oznacza to jednak, że działajaca
˛ aplikacja nie może być testowana w sposób zautomatyzowa-
ny. Dost˛epne sa˛ narz˛edzia „udajace”
˛ prawdziwego użytkownika – program potrafi symulować
klikni˛ecia myszka,˛ naciśni˛ecie klawisza i sprawdzać zawartość okna aplikacji.
25 / 61
Przykład 6. Przykładowy test aplikacji działajacej

˛ przez WWW dost˛epnej przez
przegladark˛
˛ e (zapis w pseudokodzie):
1 otwórz stron˛
e główna˛ aplikacji http://serwertestowy/aplikacja
2 sprawdź, czy na stronie jest dost˛
epny obrazek o~identyfikatorze ,,logo’’
3 odnajdź na stronie pole o~nazwie ,,login’’ i~wpisz w~nie ,,jankow’’
4 odnajdź na stronie pole o~nazwie ,,hasło’’ i~wpisz w~nie ,,abc’’
5 odnajdź na stronie przycisk o~nazwie ,,submit’’ i~wciśnij go
6 poczekaj na załadowanie odpowiedzi
7
8 sprawdź adres strony, czy jest on równy http://serwertestowy/aplikacja
epny obrazek o~identyfikatorze ,,logo’’
epny element <div> o~identyfikatorze ,,bład’’
˛
11 sprawdź, czy jego zawartość to ,,Niepoprawne hasło’’
12 odnajdź na stronie pole o~nazwie ,,login’’ i~wpisz w~nie ,,jankow’’
13 odnajdź na stronie pole o~nazwie ,,hasło’’ i~wpisz w~nie ,,abcdef’’
14 odnajdź na stronie przycisk o~nazwie ,,submit’’ i~wciśnij go
16
17 sprawdź adres strony, czy jest on równy http://serwertestowy/aplikacja/stronaGlowna
epny przycisk o~identyfikatorze ,,wyloguj’’ i~wciśnij go
Nakład pracy potrzebny do stworzenia i utrzymywania zautomatyzowanych testów

działajacej
˛ aplikacji jest wi˛ekszy niż przygotowanie dokumentu w edytorze tekstów b˛eda-
˛
cego scenariuszem testów, jednak niesie też za soba˛ znaczne korzyści – o czym jest mowa
dokładniej w rozdziale 1.5.
Podstawowa˛ przewaga˛ automatycznych testów nad r˛ecznymi jest odtwarzalność.
Znaczy to, że raz zaprogramowany test można uruchamiać automatycznie wielokrotnie, co
pozwala w przypadku napotkania jakiegoś bł˛edu na jego skuteczna˛ identyfikacj˛e i śledzenie
przyczyny. Nie jest to tymczasem możliwe w podejściu, w którym człowiek r˛ecznie wyko-
nuje scenariusz testowy i zapisuje wyniki. Scenariusz napisany dla człowieka nie jest nigdy
precyzyjny w 100%, zostawia pewien margines swobody (np. co do tego, czy korzysta si˛e
z myszki, czy z klawiatury do zaznaczenia pola itd.), który może spowodować niemożność
odtworzenia bł˛edu.
Druga˛ zaleta˛ zautomatyzowanych testów jest wi˛eksza efektywność – jak w przy-
padku każdej automatyzacji. Automatyczny test może sprawdzić w tym samym czasie dużo
wi˛ecej przypadków, zestawów danych itp. niż człowiek.
O dużym zainteresowaniu tego typu rozwiazaniami
˛ może świadczyć fakt, że na ryn-
ku dost˛epnych jest wiele różnego rodzaju aplikacji do automatycznego testowania interfejsu
użytkownika.
26 / 61
1.3.8 Powiadomienie o wyniku integracji

Środowiska ciagłej
˛ integracji swoje działanie opieraja˛ si˛e na automatycznym proce-
sie integracji. Integracja poszczególnych aplikacji nast˛epuje zatem w sposób niewymagajacy
˛
interakcji z ludźmi. Niemniej zachodzi potrzeba raportowania i powiadamiania o wynikach
integracji.
Interfejs użytkownika środowiska ciagłej

˛ integracji
Podstawowym i najcz˛eściej wyst˛epujacym

˛ narz˛edziem do przekazywania informa-
cji o stanie integracji projektów jest panel kontrolny serwera ciagłej
˛ integracji, najcz˛eściej
dostarczany jako interfejs użytkownika dost˛epny przez przegladark˛
˛ e internetowa.˛ Taki panel
kontrolny ma dwojakie zastosowanie. Umożliwia po pierwsze podglad
˛ ostatnio przeprowa-
dzanych prób integracji, a po drugie – wpływanie na najbliższe próby.
Podglad
˛ prób integracji sprowadza si˛e przede wszystkim do poinformowania o sta-
nie każdego z projektów – poprawnym czy niepoprawnym; poza tym obejmuje:
• Udost˛epnienie raportu próby integracji, który jest budowany na podstawie danych wyj-
ściowych wszystkich narz˛edzi zestawionych w procesie integracji. Przykładowymi skła-
dowymi raportu sa:
˛ komunikat końcowy kompilatora, raport narz˛edzia testujacego
˛ o wy-
niku przeprowadzonych testów, raport narz˛edzia mierzacego
˛ pokrycie kodu źródłowe-
go aplikacji testami itp.
• Udost˛epnienie poprzednich, historycznych raportów. Ma to na celu umożliwienie śle-

dzenia zmian kodu źródłowego i stanu aplikacji.
• Śledzenie integracji w trakcie jej działania.
Co prawda sam proces integracji jest zautomatyzowany, jednak zwykle w wyniku

ludzkiej interwencji może zmieniać swój przebieg. Najcz˛eściej sa˛ to polecenia:
• wyłaczenia
˛ tymczasowo i właczenia
˛ ponownie danego projektu z/do procesu automa-
tycznej integracji,
• zlecenia przeprowadzenia próby integracji w danej chwili niezależnie od harmonogra-

mu prób ustalonego na stałe,
• zaniechania trwajacej
˛ próby integracji.
27 / 61
Aktywne powiadomienia o wynikach integracji
Interfejs użytkownika środowiska ciagłej

˛ integracji potrafi dostarczać informacji na
każde żadanie
˛ użytkownika. W środowiskach ciagłej
˛ integracji stosuje si˛e cz˛esto inne sposo-
by powiadamiania – w tym takie, które same inicjuja˛ komunikacj˛e.
Najcz˛eściej serwer ciagłej
˛ integracji jest tak skonfigurowany, by informował o wy-
niku próby integracji za pomoca˛ poczty elektronicznej. Co ciekawe, adresatami takiej wiado-
mości, poza liderami projektu, sa˛ najcz˛eściej wszystkie osoby, które dokonały jakiejkolwiek
zmiany kodu źródłowego aplikacji od czasu ostatniej pomyślnej próby integracji. W przypad-
ku niepomyślnej próby integracji ma to ogromne znaczenie, ułatwia bowiem zdiagnozowanie
bł˛edu i pozwala ustalić, kto wprowadził zmian˛e, który przyczyniła si˛e do porażki próby in-
tegracji. W oczywisty sposób serwer ciagłej
˛ integracji nie ma możliwości ustalenia, który
z autorów popełnił bład,
˛ ale porównanie stanu aplikacji obecnej ze stanem z czasu ostatniej
pomyślnej próby pozwala zaw˛ezić krag
˛ „podejrzanych”.
Naturalnie poczta elektroniczna nie jest jedynym medium, które może zostać wyko-
rzystane do wysłania informacji o wyniku integracji. Niektóre z serwerów ciagłej
˛ integracji
pozwalaja˛ na ustawienie powiadomienia za pomoca˛ innych środków komunikacji – komuni-
katorów internetowych czy kanałów RSS.
Zastosowanie takich powiadomień ułatwia kierownikom projektu zmobilizowanie
członków zespołu do odpowiedzialnego współtworzenia kodu źródłowego aplikacji. List
elektroniczny z informacja˛ o niepomyślnej próbie integracji z lista˛ ostatnio wprowadzonych
zmian i ich autorów stanowi w pewien sposób presj˛e na zespół programistyczny wymuszaja-
˛
ca˛ wi˛eksza˛ dbałość o jakość zmian.
Dlatego jak wskazuje [Duv07] należy wystrzegać si˛e sytuacji, w których w wyniku
bł˛ednej konfiguracji środowisko ciagłej
˛ integracji działa niestabilnie. Może to si˛e objawiać
fałszywymi alarmami – tj. niepomyślnymi próbami integracji w sytuacji, gdy taka próba
powinna si˛e powieść. W konsekwencji niepomyślna próba skutkuje rozesłaniem nieuzasad-
nionych powiadomień do członków zespołu. Po kilku takich sytuacjach osoby zaangażowane
w projekt maja˛ tendencj˛e do ignorowania powiadomień serwera ciagłej
˛ integracji, co wytraca
˛
z r˛eki jedno z narz˛edzi kierownika projektu.
Powiadamianie przez kanał RSS
Wi˛ekszość serwerów ciagłej

˛ integracji w sposób wbudowany udost˛epnia możliwość
publikowania wyników integracji przez kanał RSS. W najprostszym podejściu każda próba
integracji jest publikowana jako jedna wiadomość RSS. Niektóre z produktów pozwalaja˛ na
28 / 61
tworzenie własnych kanałów, które każdy użytkownik może dostosować do swoich potrzeb
– np. przez wybranie interesujacych
˛ go projektów.
Kanały RSS sa˛ usługa˛ sieciowa,˛ do której dost˛epne jest wiele narz˛edzi. Co wi˛ecej
czytnik RSS może być wykorzystywany do otrzymywania informacji z wielu różnych źródeł.
Tym samym zastosowanie kanałów RSS jako narz˛edzia do informowania programistów przez
serwer ciagłej
˛ integracji może okazać si˛e wygodne i proste do wdrożenia.
Inne urzadzenia
˛ do informowania o stanie projektu
Ciekawy przykład zupełnie innego sposobu informowania o stanie projektów zarza-

˛
dzanych przez serwer ciagłej
˛ integracji podano w [Sav04]10 . A. Savoia przedstawia tam po-
mieszczenia zespołów programistycznych, w których zainstalowano różnego rodzaju świetl-
na˛ sygnalizacj˛e obecnego stanu poprawności aplikacji zarzadzanych
˛ in-
tegracji. W najprostszym podejściu wykorzystywane sa˛ ozdobne lampy (ang. lava lamps czy
Ambient ORB) w dwóch kolorach – zielonym i czerwonym. W danym momencie świeci si˛e
tylko jedna z nich jednoznacznie wskazujac
˛ obecny stan aplikacji.
W innym biurze zainstalowane dodatkowe monitory zamontowane pod sufitem w po-
mieszczeniu programistów – podobnie do wyświetlaczy informacyjnych na lotniskach czy
stacjach kolejowych. Pokazuja˛ one nieustannie obecny stan wszystkich aplikacji – również
za pomoca˛ symboli dwóch kolorów. Wyświetlacze umieszczono w ten sposób, by informacja
była z daleka widoczna i czytelna na pierwszy rzut oka. W zamyśle motywuje to cały zespół
do wspólnej troski o stan aplikacji.
Można spotkać si˛e też z opisem dźwi˛ekowego powiadomienia o negatywnej próbie
integracji – w postaci krótkiego, ale donośnego dźwi˛eku odgrywanego z głośników. Taki
sposób informowania wydaje si˛e co prawda ciekawy, wprowadza pewien element humoru do
zespołu, jednak wydaje si˛e być przesadnie ingerujacym
˛ w spokój i skupienie potrzebne do
pracy. Niemniej warto pami˛etać o takiej możliwości.
Można wyobrazić sobie również wykorzystanie innych mediów komunikacyjnych
do powiadomień o wynikach integracji – np. telefonów komórkowych i wysyłania wyników
integracji, zwłaszcza tych negatywnych, w postaci wiadomości tekstowej SMS (patrz rysu-
nek 1.9).
10
Por. http://www.tfsbuild.com/Default.aspx?Page=ControlLavaLampsAndStreetLights
29 / 61
Rysunek 1.9: Schemat wymiany informacji w środowisku ciagłej

˛ integracji
z wykorzystaniem wiadomości SMS.
1.3.9 Oznaczenie kodu źródłowego
Środowisko ciagłej
˛ integracji może zostać wykorzystane w procesie zarzadzania
˛
wersjami oprogramowania. Podstawa˛ do tego jest spostrzeżenie, że serwer ciagłej
˛ integra-
cji w pewien sposób sprawdza stabilność i jakość zarzadzanej
˛ przez siebie aplikacji. Istota˛
publikowania nowej wersji produktu jest sprawdzenie, czy spełnia ona postawione wobec niej
oczekiwania. Serwer ciagłej
˛ integracji z natury rzeczy wspomaga taka˛ kontrol˛e. Publikowa-
nie nowej wersji programu ma sens oczywiście jedynie wtedy, gdy serwer ciagłej
˛ integracji
wskazuje pozytywny stan aplikacji.
30 / 61
Jeśli tylko całość procesu integracji zakończyła si˛e pomyślnie i bezbł˛ednie, warto
zapisać stan kodu źródłowego. Pozwala to w każdej chwili wrócić do ostatniej działajacej
˛
wersji. Taka wersja nie może oczywiście stanowić wersji stabilnej aplikacji, jednak nadaje
si˛e do testowania funkcji ostatnio dodanych do aplikacji. Repozytoria kodu umożliwiaja˛ ety-
kietowanie plików. Oznaczenie może wi˛ec polegać na przypisaniu etykiety całemu kodowi
źródłowemu aplikacji. Schematycznie takie przesyłanie informacji z serwera ciagłej
˛ integra-
cji do repozytorium kodu zostało przedstawione na rysunku 1.10.
Rysunek 1.10: Schemat interakcji w środowisku ciagłej

˛ integracji, w którym nast˛epuje
zwrotna informacja z serwera ciagłej
˛ integracji do repozytorium kodu.
Jak twierdzi [Duv07], niezwykle ważnym efektem działania środowiska ciagłej

˛ inte-
gracji jest udost˛epnianie ostatniej działajacej
˛ wersji aplikacji w postaci zbudowanej i gotowej
do użytku. Dzi˛eki temu każdy posiadajacy
˛ dost˛ep do środowiska ciagłej
˛ integracji może taka˛
wersj˛e pobrać i zaczać
˛ z niej korzystać.
31 / 61
Nie jest to jedyne zastosowanie serwerów ciagłej

˛ integracji w procesie zarzadza-
˛
nia wersjami. Serwer ciagłej
˛ integracji może zostać tak skonfigurowany, by publikował no-
we wersje w sposób automatyczny. W zależności od procesu wytwarzania oprogramowania
wdrożonego w projekcie serwer ciagłej
˛ integracji może publikować:
• Nocne wersje (ang. nightly builds) – sa˛ to wersje programu automatycznie budowa-
ne w regularnych odst˛epach czasu – najcz˛eściej w odst˛epach jednodniowych o ściśle
określonej porze. Swoja˛ nazw˛e wzi˛eły z tego, że zwykle buduje si˛e je w nocy, kiedy
nie sa˛ prowadzone żadne prace programistyczne.
• Wersje kandydackie (ang. candidate releases) – sa˛ to wersje prywatne ogłaszane zwy-
kle w czasie poprzedzajacym
˛ czas ogłoszenia publicznej wersji. Prywatne wersje służa˛
do użytku wewn˛etrznego jako materiał do testowania aplikacji przed dostarczeniem jej
klientowi.
Należy podkreślić, że samego procesu ogłaszania wersji nie można w wi˛ekszości
sytuacji w pełni zautomatyzować. Automatycznie ogłaszane wersje sa˛ przetestowane jedynie
w tym zakresie, w jakim serwer ciagłej
˛ integracji testuje aplikacj˛e, a zwykle nie jest to stopień
zadowalajacy.
˛ Tak wi˛ec środowiska ciagłej
˛ integracji jedynie wspomagaja˛ wersjonowanie,
nie sa˛ w stanie w pełni go zautomatyzować.
Przykład 7. Przykładem środowiska ciagłej

˛ integracji, które w swoim założeniu
kładzie duży nacisk na zarzadzanie
˛ wersjami oprogramowania, jest Cruise – produkt firmy
ThoughtWorks (tej samej, która stworzyła aplikacj˛e CruiseControl – wi˛ecej o niej w rozdzia-
le 2.1.1).
1.4 Produkty ciagłej

˛ integracji
Efektem działania wi˛ekszości etapów integracji sa˛ pewne produkty. Niekiedy pro-
duktem bywa to prosta informacja – pozytywny/niepozytywny, z kolei czasem sa˛ to raporty,
zestawienia czy wr˛ecz gotowa aplikacja.
Wartym podkreślenia jest fakt, że etapy integracji wytwarzaja˛ produkty nawet jeśli
kończa˛ si˛e z wynikiem negatywnym. Wtedy nawet raport uruchomionego narz˛edzia (np. do
testowania) zawiera informacj˛e o obserwowanych usterkach, watpliwych
˛ fragmentach kodu
itp.
32 / 61
Najważniejsze produkty integracji zostały wyszczególnione w poniższej tabeli –

z podziałem na etapy, w których moga˛ powstawać.
Etap integracji Produkty etapu

Budowanie Aplikacja w postaci gotowej do uruchomienia
– tj. wszystkie pliki potrzebne do uruchomienia
aplikacji.
Testowanie Raporty testów narz˛edzi używanych do testo-
wania, w szczególności zestawienie wszystkich
uruchomionych testów, ich wyników (pozytyw-
ny, negatywny), komunikatów bł˛edów (w przy-
padku negatywnego wyniku), czasu trwania.
Najcz˛eściej wyst˛epuje w postaci pliku PDF lub
jednej strony HTML. Dodatkowym produktem
tego etapu może być również raport narz˛edzia
mierzacego
˛ pokrycie kodu testami.
Przeglad
˛ kodu Raporty narz˛edzi do automatycznego przegla-
˛
du kodu, w tym wyszczególnienie wszystkich
bł˛edów, usterek i ostrzeżeń. Czasami podsumo-
wanie działania takiego narz˛edzia zawiera tyl-
ko list˛e nazwy plików i numery linii, w których
wyst˛epuja˛ uchybienia. Bardziej zaawansowane
narz˛edzia kopiuja˛ fragment kodu źródłowego
zaznaczajac
˛ ostrzeżenia bezpośrednio w kodzie
źródłowym.
Uruchomienie aplikacji Informacja o tym, jak skorzystać z uruchomio-
nej aplikacji, np. w przypadku programów do-
st˛epnych przez przegladark˛
˛ e b˛edzie to hiperła-
˛
cze do aplikacji.
Tabela 1.1: Produkty poszczególnych etapów integracji.

33 / 61
1.5 Korzyści z zastosowania ciagłej

˛ integracji w wytwarza-
niu oprogramowania
Zastosowanie ciagłej
˛ integracji niesie za soba˛ wiele korzyści – zarówno doraźnych,
których efekty widać w danym projekcie, jak i długoterminowych, na których moga˛ sko-
rzystać przyszłe projekty prowadzone przez organizacj˛e. Pogrupowane w kategorie korzyści
opisano w kolejnych podrozdziałach.
1.5.1 Jakość tworzonego oprogramowania
Serwery ciagłej
˛ integracji nie wpływaja˛ bezpośrednio na jakość produktu, jakim
jest oprogramowanie. Pozwalaja˛ jedynie t˛e jakość kontrolować; środowisko ciagłej
˛ integracji
należy wi˛ec raczej postrzegać jako miernik jakości wytwarzanego oprogramowania.
Niemniej do korzyści z wdrożenia ciagłej
˛ integracji w procesie produkcji oprogra-
mowania należy zaliczyć wymuszenie automatyzacji testów (i innych mechanizmów kontroli
jakości opisanych w poprzednich rozdziałach). Jak wspomniano, ogromna˛ zaleta˛ automa-
tycznych testów jest ich powtarzalność. Raz skonstruowany test może zostać przeprowadzo-
ny przez komputer wielokrotnie – w przeciwieństwie do r˛ecznych testów, w których nakład
czasu i zasobów potrzebny do przeprowadzania testu jest w zasadzie identyczny za każdym
razem. Dzi˛eki testom automatycznym możliwe jest ciagłe
˛ testowanie aplikacji, co z kolei
pozwala stale kontrolować jej jakość.
Jak podkreśla M. Fowler w pracy [Fow06] ogromne znaczenie ma też fakt, że przy
zastosowaniu ciagłej
˛ integracji skraca si˛e średni czas od powstania bł˛edu do jego naprawie-
nia. Dzieje si˛e tak dlatego, że tuż po wprowadzeniu bł˛ednego kodu do repozytorium, serwer
ciagłej
˛ integracji pobiera go i sprawdza, próbujac
˛ budować aplikacj˛e. W przypadku wykrycia
bł˛edu, serwer ciagłej
˛ integracji zgłasza bład
˛ i powiadamia o tym zainteresowanych progra-
mistów w czasie rz˛edu minut od dokonania zmiany. Dzi˛eki temu twórcy sa˛ na bieżaco
˛ ze
zmienianym fragmentem aplikacji i nie musza˛ poświ˛ecać czasu na przypomnienie architek-
tury. W podejściu tradycyjnym bł˛edy sa˛ najcz˛eściej wykrywane dużo później, tj. pod koniec
projektu, albo co gorsza po wdrożeniu produktu do użytku, kiedy naprawienie bł˛edu jest dużo
bardziej kosztowne.
M. Fowler w [Fow06] zwraca również uwag˛e na psychologiczny aspekt szybkiego
poprawiania bł˛edów. Odwołujac
˛ si˛e do tzw. zjawiska wybitych okien (ang. Broken Windows
34 / 61
Syndrome)11 postuluje jak najszybsze poprawianie usterek. Jego zdaniem dłuższe pozosta-
wanie nienaprawionych bł˛edów skutkuje mniejsza˛ dbałościa˛ programistów. Widzac
˛ niena-
prawione bł˛edy programiści sa˛ mniej ostrożni i łatwiej o nowe usterki.
Z kolei V. Subramanian w [Sub04] zauważa, że automatyzacja procesu budowa-
nia umożliwia wspieranie różnych konfiguracji systemowych – np. uruchamianie aplikacji
na różnych platformach sprz˛etowych, testowanie z użyciem różnych systemów zarzadzania
˛
baza˛ danych, testowanie webowego interfejsu użytkownika z użyciem różnych przegladarek
˛
internetowych itd. W wi˛ekszości organizacji programiści na swoich komputerach instaluja˛
tylko jedna˛ ze wspieranych konfiguracji. Nie sposób wymagać, by każdy z nich instalował
u siebie różne systemy operacyjne, systemy baz danych, przegladarki
˛ i stworzony przez sie-
bie kod testował w działaniu w wielu konfiguracjach.
1.5.2 Gotowość do użycia
Ważna˛ cecha˛ środowisk ciagłej

˛ integracji jest udost˛epnianie przez nie ostatniej dzia-
łajacej
˛ wersji aplikacji – zarówno w formie działajacej
˛ aplikacji uruchomionej na serwerze
testowym, jak i gotowej wersji instalacyjnej. Dzi˛eki temu możliwe jest śledzenie post˛epu roz-
woju aplikacji, udost˛epnienie jej do wgladu
˛ osobom spoza zespołu programistycznego (np.
klientowi), przygotowywanie dokumentacji użytkownika (w tym zrzutów ekranu) itp. Praca
[Sub04] podkreśla wag˛e tej cechy w projektach prowadzonych w sposób zwinny, w których
przecież dalszy plan rozwoju aplikacji zmienia si˛e stosunkowo cz˛esto.
Jedna z dwunastu głównych zasad wymienionych w Manifeście Zwinnego Oprogra-
mowania12 brzmi
Najwyższym priorytetem dla nas jest satysfakcja klienta osiagana

˛ przez wczesne
i ciagłe
˛ dostarczanie wartościowego oprogramowania.
Godnym podkreślenia jest obserwacja, że ciagła

˛ integracja doskonale pomaga wy-
pełniać t˛e misj˛e. Dzi˛eki zastosowaniu ciagłej
˛ integracji twórcy oprogramowania stale kontro-
luja˛ jego jakość, która przekłada si˛e wprost na wartość dla klienta.
11
Broken Windows Syndrome – teoria socjologiczna oparta na obserwacji stanu budynków miejskich. Jeśli
wybita szyba nie zostaje szybko wymieniona, zaczyna si˛e pojawiać coraz wi˛ecej wybitych szyb w sasiednich
˛
oknach. Jedno uchybienie pozostajace
˛ długo nienaprawione świadczy o przyzwoleniu na nast˛epne uchybienia.
12
Patrz [Man01].
35 / 61
Co wi˛ecej, poprawne użycie ciagłej

˛ integracji gwarantuje pewien poziom jakości
nawet w przypadku nagłego przerwania projektu. W przedsi˛ewzi˛eciach prowadzonych meto-
dykami tradycyjnymi zatrzymanie rozwoju aplikacji zwykle skutkuje niedostarczeniem żad-
nego fragmentu planowanej aplikacji. Inaczej rzecz si˛e ma w projektach zwinnych, w któ-
rych przerwanie projektu zdarza si˛e i nie oznacza natychmiastowej katastrofy. Niezależnie
od metodyki w momencie przerwania prac w projekcie, jeśli była stosowana w nim ciagła
˛
integracja, można si˛egnać
˛ po ostatnia˛ działajac
˛ a˛ wersj˛e aplikacji. Możliwe, że po drobnych
zmianach byłoby możliwe wdrożenie takiej aplikacji i jej funkcjonowanie jako cz˛eściowe
rozwiazanie.
˛
1.5.3 Zarzadzanie
˛ zmianami
Bolaczk
˛ a˛ prawie każdego projektu informatycznego sa˛ zmiany założeń w trakcie
prowadzenia projektu. Biora˛ si˛e one z wielu powodów – jak na przykład zmian potrzeb zama-
wiajacego
˛ w czasie trwania projektu czy bł˛ednego zdefiniowania jego celów. Jest to zjawisko
nieuchronne i ciagła
˛ integracja nie jest w stanie mu zapobiec, ale może pomóc minimali-
zować jego skutki. Jak napisano w poprzednim podrozdziale, dzi˛eki stałemu utrzymywaniu
aplikacji w poprawnym stanie można wdrożyć procedur˛e wgladu
˛ zamawiajacego
˛ w bieżacy
˛
stan rozwijanej aplikacji. Pozwala to w sposób proaktywny przygotowywać si˛e na zmiany.
Im wcześniej zostana˛ zgłoszone żadania
˛ zmian, tym mniej kosztowne jest ich uwzgl˛ednienie.
Z takiego rozwiazania
˛ korzyści czerpie zarówno dostawca, jak i zamawiajacy
˛ produkt infor-
matyczny – dostawca może planować dalsze kroki w pewniejszy sposób, a zamawiajacy
˛ nie
jest narażony na ryzyko opóźnienia projektu czy zwi˛ekszenia jego kosztów.
Doskonale wpisuje si˛e to w koncepcj˛e zwinnych metod zarzadzania
˛ projektem in-
formatycznym, których nadrz˛ednym celem jest satysfakcja zamawiajacego
˛ – w przeciwień-
stwie do projektów prowadzonych w sposób tradycyjny, w których priorytetem jest zgodność
z poczatkow
˛ a˛ specyfikacja.˛
1.5.4 Usprawnienie procesów

Niezwykle ważna˛ korzyścia˛ z wprowadzenia podejścia ciagłej
˛ integracji jest oszcz˛ed-
ność czasu poświ˛ecanego na powtarzalne procesy.
W tradycyjnym podejściu zadania takie jak integracja pracy wykonanej przez po-
szczególne podzespoły, uruchomienie aplikacji, zakładanie i utrzymywanie zawartości bazy
danych sa˛ wykonywane r˛ecznie, co w prosty sposób przekłada si˛e na koszty organizacji.
36 / 61
Automatyzacja takich procesów pozwala na zaoszcz˛edzenie tego czasu. Zamiast

r˛ecznego wykonywania pewnych procesów dzieja˛ si˛e one automatycznie – a dzi˛eki temu
przebiegaja˛ szybciej i można mieć wi˛eksza˛ pewność co do ich prawidłowości.
Przy bilansie zysków i kosztów należy pami˛etać o czasie poświ˛econym na automa-
tyzacj˛e procesów. Jednak istotne jest to, że automatyzacja procesów jest zwykle czynnościa˛
jednorazowa,˛ można wi˛ec o niej myśleć jako o inwestycji, która po jakimś czasie si˛e zwróci.
1.6 Koszty wprowadzenia i utrzymania ciagłej

˛ integracji
Niewatpliwie,
˛ jak opisano w rozdziale 1.5 wdrożenie środowiska ciagłej
˛ integracji
w projekcie informatycznym przynosi pewne korzyści. Jednak ich uzyskanie trzeba okupić
pewnymi kosztami – zarówno jednorazowymi, jak i stałymi.
Wśród jednorazowych nakładów z pewnościa˛ należy wymienić:
• Ewentualny koszt zakupu oprogramowania – serwera ciagłej

˛ integracji. Wi˛ekszość
rozwiazań
˛ jest darmowych. Za niektóre trzeba zapłacić, ale zwykle sa˛ to bardziej roz-
budowane wersje bezpłatnych produktów.
• Koszt zakupu sprz˛etu. Wi˛ekszość praktyków ciagłej

˛ integracji radzi nie szukać nad-
miernych oszcz˛edności przy zakupie sprz˛etu do instalacji serwera ciagłej
˛ integracji.
Jest niezwykle ważne, by czas trwania próby integracji był najkrótszy, co ma prze-
łożenie na szybkość powiadomienia programistów o ew. bł˛edzie, co z kolei wpływa
˛ na szybkość poprawiania bł˛edów13 .
znaczaco
• Przekonanie zespołu programistycznego do nowego sposobu pracy. Poczatkowo

˛
zespół programistyczny może być nastawiony niech˛etnie do idei ciagłej
˛ integracji. Nie-
watpliwie
˛ przystosowanie si˛e do pracy według koncepcji ciagłej
˛ integracji wymaga
przestawienia si˛e i zmiany nawyków. Niestety bez współpracy wszystkich członków
zespołu wdrożenie ciagłej
˛ integracji si˛e nie powiedzie.
• Nakład pracy na automatyzacj˛e testów. Ciagła

˛ integracja z założenia opiera si˛e
na automatyzacji procesu integracji. Osiagni˛
˛ ecie stanu, w którym cała integracja jest
zautomatyzowana wymaga pewnej pracy. Jej skala i istota zależa˛ od konkretnego pro-
jektu. W wi˛ekszości przypadków stanowi to na tyle ważna˛ pozycj˛e w bilansie zysków
i strat, że nie należy jej pominać.
˛
13
Por. [Duv07].
37 / 61
Środowisko ciagłej
˛ integracji b˛edzie wymagało nieustannych nakładów z powodu
konieczności wyznaczenia osób odpowiedzialnych za nadzorowanie każdego z projektów za-
rzadzanych
˛ integracji. Praktyka zastosowania ciagłej
˛ integracji pokazuje,
że mimo automatyzacji integracji ważne jest, by każdy z projektów miał swojego opiekuna.
Jest on odpowiedzialny za dbanie o to, by projekt był możliwie cz˛esto w poprawnym stanie.
Nie oznacza to obowiazku
˛ samodzielnego naprawiania bł˛edów, ale zadaniem takiej osoby jest
wyznaczanie, kto z programistów ma si˛e zajać
˛ naprawianiem bł˛edu. Nie zawsze komunikat
bł˛edu z testów jednoznacznie wskazuje „winnego” powstania bł˛edu – zwłaszcza gdy kilka
osób pracuje nad jednym fragmentem aplikacji. Innym zadaniem pozostaje naprawianie bł˛e-
dów niewynikajacych
˛ z samego kodu aplikacji, jak na przykład usterek całej infrastruktury
integracji danego projektu.
38 / 61
Rozdział 2
Praktyka wykorzystania ciagłej

˛ integracji
Rynek serwerów ciagłej

˛ integracji jest całkiem bogaty i oferuje szereg rozwiazań,
˛
wi˛ekszość dost˛epnych produktów dostarcza podobny zakres funkcjonalności. Dlatego dobór
optymalnego rozwiazania
˛ w pierwszej chwili może wydawać si˛e trudny. Podczas wyboru
konkretnego produktu zasadnym wydaje si˛e zwrócenie uwagi na nast˛epujace
˛ cechy produk-
tów:
• cen˛e i dost˛epność źródeł,
• obsług˛e używanych w projekcie narz˛edzi do:
– budowania,
– komunikacji z repozytorium kodu,
– testowania,
• elastyczna˛ architektur˛e konfiguracji i jej rozszerzalność,
• skalowalność.
W tabeli 2.1 zostało przedstawione zestawienie najbardziej popularnych serwerów

ciagłej
˛ integracji. Bardziej szczegółowe porównanie znanych produktów można znaleźć w [mat],
gdzie porównano kilkadziesiat
˛ różnych cech aplikacji.
39 / 61
Nazwa Twórca Dost˛epne źródła Darmowy

CruiseControl ThoughtWorks TAK TAK
CruiseControl.NET ThoughtWorks TAK TAK
CruiseControl.rb ThoughtWorks TAK TAK
Cruise ThoughtWorks NIE TAK/NIE14
CI Factory Jay Flowers TAK TAK
Drumbeat CI Timpani Software NIE NIE15
Tinderbox i Tinderbox2 Mozilla Project TAK TAK
BuildBot Brian Warner TAK TAK
Anthill Professional Urbancode NIE NIE16
Anthill Urbancode TAK TAK
Bamboo Atlassian NIE17 NIE
Luntbuild professional PMEase NIE17 NIE
LuntBuild PMEase TAK TAK
Gump Apache Gump TAK TAK
Continuum Apache TAK TAK
Sin CSH Consult TAK TAK
OpenMake Meister OpenMake Software NIE NIE
OpenMake Mojo OpenMake Software NIE TAK
Parabuild Viewtier Systems NIE17 NIE
Tinderbox3 John Keiser TAK TAK
Pulse Zutubi NIE17 NIE
TeamCity JetBrains cz˛eściowo NIE18
Hudson java.net TAK TAK
FinalBuilder Server VSoft Technologies NIE NIE
Zed Hericus Software NIE NIE18
Tabela 2.1: Najbardziej popularne serwery ciagłej

˛ integracji.
Źródło: Opracowanie własne na podstawie [mat].
W kolejnych podrozdziałach zostały opisane trzy popularne serwery ciagłej

˛ integra-
cji. Mi˛edzy innymi przedstawiono ich interfejs użytkownika oraz wymieniono najważniejsze
cechy, którymi si˛e wyróżniaja˛ na tle innych rozwiazań.
˛ Wybrane produkty to: CruiseControl,
TeamCity i Hudson.
40 / 61
2.1 Wybrane rozwiazania

˛
2.1.1 CruiseControl
CruiseControl19 jest darmowym serwerem ciagłej

˛ integracji, rozwijanym przez śro-
dowisko wolnego oprogramowania, dost˛epnym na licencji typu BSD (Berkeley Software Di-
stribution). Powstał jako wewn˛etrzny produkt firmy ThoughtWorks20 . A nast˛epnie został udo-
st˛epnione publicznie wszystkim zainteresowanym.
Jest to najpopularniejszy serwer ciagłej
˛ integracji na rynku21 , o najdłuższej tradycji –
ch˛etnie stosowany ze wzgl˛edu na swoja˛ przyst˛epność, szeroka˛ funkcjonalność i elastyczność.
Interfejs użytkownika
Głównym interfejsem użytkownika serwera CruiseControl jest aplikacja Dashboard.
Rysunek 2.1: Główny widok aplikacji Dashboard – interfejsu użytkownika aplikacji

CruiseControl.
19
W dosłownym tłumaczeniu mianem „cruise control” określa si˛e tempomat – urzadzenie
˛ stosowane np.
w samochodach, które samoczynnie utrzymuje zadana˛ pr˛edkość podróżna.˛
20
W firmie ThoughtWorks przez wiele lat pracował wspomniany wielokrotnie w tej pracy M. Fowler.
21
Według badań przedstawionych w [Fle09] CruiseControl ma 42-procentowy udział w rynku.
41 / 61
Jak widać na rysunku 2.1, interfejs aplikacji jest całkiem czytelny – kolorem zielo-
nym oznaczono projekty, które sa˛ w poprawnym stanie; kolorem czerwonym – te, których
ostatnia próba integracji si˛e nie powiodła. W aplikacji Dashboard możliwe jest m.in.:
• ogladanie
˛ stanu każdego z zarzadzanych
˛ projektów,
• śledzenie post˛epu prób integracji obecnie si˛e odbywajacych,

˛
• obejrzenie dokładnego opisu wyniku ostatniej (i poprzednich) próby integracji – w tym

wyniku działania kompilatora, raportu testów, raportu innych narz˛edzi właczonych
˛ w
proces integracji,
• r˛eczne wymuszenie próby integracji wybranego projektu.
Wi˛ekszość operacji z zakresu codziennej obsługi systemu można wykonać przez

interfejs aplikacji Dashboard. Niemniej niektórych ważnych funkcji brakuje. Na przykład –
nie jest możliwe przerwanie trwajacej
˛ próby integracji (co jest przydatne, gdy wiadomo, że
si˛e nie powiedzie) czy zmiana kolejności projektów czekajacych
˛ na integracj˛e.
Konfiguracja
Ogromna˛ zaleta˛ systemu CruiseControl jest dobrze przemyślany sposób konfiguro-

wania działania serwera integracji. Konfiguracja przechowywana jest w pliku XML, którego
struktura pozwala na elastyczne konfigurowanie wielu projektów bez konieczności kopiowa-
nia wpisów konfiguracyjnych.
Aplikacja pozwala również na dodawanie własnych wtyczek – służacych
˛ zarówno
do komunikacji z repozytoriami kodu, jak i budowania aplikacji, powiadamiania o wynikach
integracji itd. Samo narz˛edzie posiada wiele różnych funkcji, a możliwość dopisywania no-
wych pozwala na przystosowanie aplikacji CruiseControl do praktycznie każdego projektu –
tym bardziej, że dokumentacja pliku konfiguracyjnego zawiera szczegółowy opis znaczenia
wszystkich parametrów22 .
2.1.2 Hudson
Hudson jest stosunkowo młodym produktem na rynku ciagłej
˛ integracji, jednak
szybko zyskuje sobie popularność („podbierajac”
˛ użytkowników programowi CruiseCon-
trol).
22
Patrz: http://cruisecontrol.sourceforge.net/main/configxml.html.
42 / 61
Twórca˛ Hudsona jest Kohsuke Kawaguchi23 , zatrudniony w Sun Microsystems. Apli-

kacja Hudson jest udost˛epniana na licencji MIT (Massachusetts Institute of Technology),
która dopuszcza darmowe zastosowania na różne potrzeby.
Interfejs użytkownika i konfiguracja
W zamyśle program jest konfigurowalny w 100% przez interfejs przegladarkowy.

˛
Wewn˛etrznie każdy projekt posiada własna˛ konfiguracj˛e w postaci pliku XML-owego, jednak
poza zaawansowanymi zastosowaniami nie ma potrzeby jego edycji.
Dlatego prac˛e z tym serwerem ciagłej
˛ integracji można zaczać
˛ od razu. Po instalacji
w kilka minut można skonfigurować istniejacy
˛ projekt tak, by był budowany przez Hudso-
na. Dodawanie nowego projektu odbywa si˛e przez przyjazny kreator projektu, który pyta
o kluczowe dane projektu – w tym parametry połaczenia
˛ do repozytorium kodu czy sposób
budowania (np. w przypadku narz˛edzia Ant, o ścieżk˛e do pliku build.xml).
Główna strona interfejsu (zrzut ekranu przedstawiono na poniższym rysunku) poka-
zuje list˛e wszystkich projektów.
Rysunek 2.2: Główny ekran aplikacji Hudson.

Źródło: http://hudson.jboss.org/hudson.
O ile projekty w niepoprawnym stanie oznaczone sa˛ „tradycyjnie” na czerwono, to

poprawne projekty wyróżnione sa˛ kolorem niebieskim, a nie – jak można by było zakładać
23
Wi˛ecej informacji na temat K. Kawaguchiego można znaleźć na jego stronach: http://weblogs.
java.net/blog/kohsuke/ oraz http://www.kohsuke.org/
43 / 61
– zielonym. Źródeł tej odmienności należy doszukiwać si˛e w różnicach kulturowych mi˛edzy
światem zachodnim a Japonia,˛ z której pochodzi autor aplikacji.
Z poczatku
˛ troch˛e nieintuicyjnym wydaje si˛e wprowadzenie jeszcze trzeciego ko-
loru, żółtego, który oznacza, że projekt jest niestabilny. Należy wtedy rozumieć, że ostat-
nia próba integracja zakończyła si˛e co prawda pomyślnie, ale któryś z jej elementów zgło-
sił ostrzeżenie. Na korzyść takiego rozwiazania
˛ w Hudsonie może świadczyć fakt, że pułap
liczby ostrzeżeń, od którego projekt jest uznawany za niestabilny, jest konfigurowalny. Nie
stanowi wi˛ec problemu praktyczne wyeliminowanie tego pośredniego stanu nazwanego nie-
stabilnym, a dodatkowa możliwość konfiguracji powinna być zawsze uznawana za zalet˛e.
W ramach uzupełnienia warto wspomnieć o klasycznym rozumieniu terminu „stabil-
ność” rozwoju aplikacji. Pod tym poj˛eciem zwykle rozumie si˛e raczej stan rozwoju aplikacji
w kontekście czasowym. Jeśli zmiany sa˛ przewidywalne i rzadko zdarza si˛e, że kod źródło-
wy jest wadliwy, to można mówić o stabilnym projekcie. Niestabilny projekt czy niestabilna
faza projektu oznacza taki okres w rozwoju aplikacji, kiedy cz˛esto zdarza si˛e, że aplikacja
nie działa poprawnie.
Co ciekawe, Hudson poza obecnym stanem aplikacji wyświetla również informacj˛e
o „zdrowiu” aplikacji. Doskonale pasuje to do opisywanego powyżej sposobu rozumienia
stabilności według K. Kawaguchiego. Wnioskujac
˛ na podstawie kilku ostatnich prób budo-
wania (czy zakończyły si˛e sukcesem czy porażka)
˛ ocenia na ile stabilny (zdrowy) jest pro-
dukt. Ikony nawiazuj
˛ a˛ do prognoz pogody – od słońca (produkt w pełni zdrowy) po burz˛e,
która wskazuje „ciemne chmury nad projektem”.
2.1.3 TeamCity
Innym rozwiazaniem
˛ dost˛epnym na rynku produktów wspomagajacych
˛ ciagł
˛ a˛ in-
tegracj˛e jest TeamCity firmy JetBrains24 . W przeciwieństwie do Hudsona i aplikacji Cru-
iseControl, TeamCity nie jest rozwijany jako otwarte oprogramowanie, jednak podstawo-
wa wersja TeamCity (Professional Edition) jest dost˛epna za darmo, można ja˛ zastosować
w mniejszych projektach (do 20 konfiguracji budowania), liczac
˛ si˛e z pewnymi ogranicze-
niami w funkcjonalności. Licencja na pełna˛ wersj˛e (Enterprise Edition) kosztuje 1700 euro.
Brak dost˛epnego kodu źródłowego aplikacji może wpływać negatywnie na elastyczność za-
stosowania tego rozwiazania
˛ w bardziej skomplikowanych konfiguracjach. Jest to z pewno-
ścia˛ informacja, której nie należy pominać
˛ przy wyborze rozwiazania
˛ ciagłej
˛ integracji.
24
Firma JetBrains jest znana w świecie Javy ze środowiska programistycznego IntelliJ IDEA, które oferuje.
Wywodzi si˛e z Czech.
44 / 61
Poj˛ecia
W serwerze TeamCity podstawowymi poj˛eciami sa:

˛
• projekt,
• konfiguracja budowania,
• agent.
Z założenia serwer TeamCity jest zbudowany w koncepcji w˛ezła głównego i wielu

agentów. W˛ezeł główny stanowi centrum sterowania ciagł
˛ a˛ integracja,˛ a agenty to programy,
które wykonuja˛ próby integracji (rozproszone przetwarzanie w ciagłej
˛ integracji zostało sze-
rzej opisane w rozdziale 2.3). Darmowa wersja umożliwia konfiguracj˛e co najwyżej trzech
agentów (płatna też, dodatkowe można dokupywać po 255 euro).
Kolejnym po „agencie” ważnym poj˛eciem w TeamCity jest „konfiguracja budowa-
nia”. W przeciwieństwie do wi˛ekszości innych serwerów ciagłej
˛ integracji (w tym Cruise-
Control i Hudsona), samo zdefiniowanie projektu nie wymaga określenia sposobu jego inte-
gracji. Dopiero do każdego projektu można doczepiać konfiguracje budowania (w darmowej
wersji – w liczbie do 20), które określaja,˛ jak ma przebiegać integracja. Doskonale to pasuje
do sytuacji, w której ten sam projekt (budowany z tych samych źródeł) buduje si˛e i uruchamia
w różnych konfiguracjach (w różnych systemach operacyjnych czy z użyciem różnych prze-
gladarek).
˛ Z kolei w zastosowaniach z pojedynczymi konfiguracjami nie stanowi to zb˛ednego
utrudnienia.
Interfejs użytkownika
Po przyswojeniu poj˛eć i struktury działania opisanych powyżej, interfejs użytkow-

nika aplikacji TeamCity wydaje si˛e być przyjazny i funkcjonalny. Dzi˛eki wyodr˛ebnieniu po-
j˛ecia „konfiguracji budowania” łatwo kontrolować stan poszczególnych elementów integracji
danego projektu (co pokazuje rysunek 2.3).
Z kolei w organizacji, w której zdecydowano si˛e na instalacj˛e i konfiguracj˛e co naj-
mniej kilku agentów budujacych,
˛ bardzo ciekawy staje si˛e panel prezentujacy
˛ aktywność
agentów – patrz rysunek 2.4. Informacja o tym, który agent czym (tj. jakim projektem) si˛e
zajmował w danym czasie, jest przedstawiana na bardzo czytelnym wykresie. Pozwala to
dobrze zarzadzać
˛ liczba˛ i konfiguracja˛ agentów w danym środowisku. Duża ilość „białych
plam” na wykresie użycia danego agenta może świadczyć o niewykorzystaniu pełnego po-
tencjału środowiska.
45 / 61
Rysunek 2.3: Przykładowy ekran aplikacji TeamCity – stan poszczególnych konfiguracji

budowania jednego projektu
Źródło: http://www.jetbrains.com/teamcity/features/screenshots.
html.
Rysunek 2.4: Przykładowy ekran aplikacji TeamCity – historia aktywności agentów

Źródło: http://www.jetbrains.com/teamcity/features/screenshots.
html.
46 / 61
2.2 Najlepsze praktyki

M. Fowler sformułował zestaw postulatów, których wypełnienie umożliwia popraw-
ne wykorzystanie koncepcji ciagłej
˛ integracji. Sa˛ one nast˛epujace:
˛
1. Utrzymywanie jednego repozytorium kodu.
2. Automatyzacja budowania.
3. Samo-testujaca
˛ si˛e integracja.
4. Każdy codziennie wgrywa kod do repozytorium.
5. Każde wgranie kodu powoduje prób˛e integracji głównej gał˛ezi projektu.
6. Szybka integracja.
7. Testowanie w kopii środowiska produkcyjnego.
8. Udost˛epnienie najnowszej wersji aplikacji gotowej do uruchomienia.
9. Przejrzystość i jawność.
10. Automatyzacja uruchomienia aplikacji.
Niektóre z powyżej wymienionych punktów – ze wzgl˛edu na ich duża˛ wag˛e – zo-

stały omówione szerzej i skomentowane w kolejnych podrozdziałach.
Utrzymywanie jednego repozytorium kodu
Repozytorium kodu jest niezb˛ednym elementem infrastruktury ciagłej

˛ integracji.
Bez niego trudno wyobrazić sobie automatyzacj˛e integracji. Można by sobie wyobrazić ta-
ka˛ organizacj˛e pracy zespołu programistów, w którym wydzielono jeden serwer, na który
wszyscy współtworzacy
˛ kod źródłowy sa˛ zobowiazani
˛ wgrywać swoje zmiany. Jednak takie
podejście cechuja˛ dość poważne wady:
• Brak mechanizmu wymuszania wgrywania zmian na serwer, co nawet przy braku

złej woli ze strony programistów, szybko skończyłoby si˛e porażka.˛ Z natury ludzkiej
wynika tendencja do zapominania o nawet najbardziej oczywistych zasadach.
47 / 61
• Brak wersjonowania – podstawowa˛ cecha˛ repozytorium kodu jest zarzadzanie

˛ wer-
sjami kodu źródłowego. Dlatego też repozytoria kodu nazywa si˛e czasem systemami
kontroli wersji (ang. version control system). Brak wersjonowania oznacza utrat˛e histo-
rii rozwoju aplikacji, co może si˛e okazać zgubne. Nie ma wtedy bowiem możliwości
cofni˛ecia si˛e do działajacej
˛ wersji sprzed jakiegoś czasu. Brakuje też możliwości śle-
dzenia zmian, co skutecznie wyklucza praktyk˛e debugowania różnicowego (ang. diff
debugging)25 .
• Brak synchronizacji pracy programistów. Im wi˛ekszy zespół, tym bardziej prawdo-

podobne i cz˛este jest wprowadzenie zmian do tego samego pliku przez dwóch różnych
członków zespołu. Repozytoria kodu trzymaja˛ piecz˛e nad spójnościa˛ zawartości i roz-
wiazuj
˛ a˛ konflikty wgrywania dwóch sprzecznych ze soba˛ zmian.
Warto jeszcze raz podkreślić, że w repozytorium kodu należy przechowywać nie
tylko kod źródłowy, ale wszystkie zapisy potrzebne do zbudowania aplikacji. Sam M. Fowler
w [Fow06] opisuje to w sposób nast˛epujacy:
˛
Wiele zespołów programistycznych korzysta z repozytoriów kodu, jednak obserwuj˛e

bład,
˛ który popełniany jest dość cz˛esto – mianowicie nieumieszczanie wszystkich informacji
w repozytorium kodu. Jeśli repozytorium jest używane, ludzie umieszczaja˛ w nim kod źródło-
wy. Jednak wszystko potrzebne do zbudowania aplikacji powinno znaleźć si˛e również w re-
pozytorium: skrypty testowe, pliki konfiguracyjne, schemat bazy danych, skrypty instalacyjne
i zewn˛etrzne biblioteki. [. . . ] Co do zasady po rozpocz˛eciu pracy z dziewiczym komputerem
i pobraniu projektu z repozytorium kodu, powinno być możliwe pełne zbudowanie aplika-
cji. W samej konfiguracji komputera wymaga si˛e absolutnego minimum – zwykle takich ele-
mentów systemu, które sa˛ obszerne, trudne do instalacji i stabilne, np. system operacyjny,
maszyna wirtualna Javy czy system zarzadzania
˛ baza˛ danych.
Samo-testujaca
˛ si˛e integracja
M. Fowler pisze:
W tradycyjnym podejściu budowanie polega na kompilacji, linkowaniu i wszystkich

innych czynnościach potrzebnych do uruchomienia programu. Jednak samo uruchomienie
25
Debugowanie przyrostowe polega na tropieniu zmian w analizowanym fragmencie aplikacji od czasu
ostatniej wersji, o której wiadomo, że działała poprawnie.
48 / 61
programu nie oznacza, że działa on poprawnie. Nowoczesne j˛ezyki o statycznym systemie
typów26 moga˛ wykrywać pewne bł˛edy, ale wiele z nich i tak prześlizgnie si˛e przez sieć.
Dobrym sposobem na wykrywanie bł˛edów w sposób szybszy i bardziej efektywny jest
właczenie
˛ automatycznych testów do procesu budowania. Testowanie oczywiście nie rozwia˛że
wszystkich problemów, ale może ujawnić wiele bł˛edów, co jest warte zachodu. W szczególno-
ści wzrost popularności Programowania Ekstremalnego (ang. Extreme Programming (XP))
oraz ang. Test Driven Development27 spowodował zainteresowanie samo-testujacym
˛ si˛e ko-
dem [. . . ].
Słowa M. Fowlera potwierdzaja˛ wag˛e da˛żenia do osiagni˛

˛ ecia jak najlepszej jakości
tworzonego oprogramowania. Narz˛edzia ciagłej
˛ integracji doskonale nadaja˛ si˛e do wspiera-
nia tych da˛żeń, dlatego niewatpliwie
˛ warto korzystać z oferowanych przez nie różnorodnych
możliwości automatycznego testowania.
Każdy codziennie wgrywa kod do repozytorium
Wdrożenie ciagłej
˛ integracji polega nie tylko na zainstalowaniu serwera; jest to tak-
że praktyka, której trzymaja˛ si˛e członkowie zespołu programistycznego28 . Polega ona na cz˛e-
stym wgrywaniu wprowadzonych przez siebie zmian do repozytorium.
Im cz˛eściej wgrywa si˛e kod do repozytorium, tym rzadziej wyst˛epuja˛ konflikty pod-
czas wgrywania (sytuacje, w których dwaj różni programiści dokonali niezależnych zmian
w tym samym pliku). Przestrzeganie reguły cz˛estego wgrywania zmian wymusza też podział
pracy na mniejsze zadania. Każde wgranie kodu jest podmiotem osobnych testów ze strony
serwera ciagłej
˛ integracji, co z kolei powoduje, że poszczególne fragmenty wi˛ekszej zmiany
sa˛ lepiej przetestowane.
26
Wśród obecnie popularnych j˛ezyków programowania j˛ezykami o statycznym systemie typów sa˛ m.in. C,
C++, C#, Java, Perl – w przeciwieństwie do j˛ezyków z dynamicznym systemem typów, takich jak: JavaScript,
PHP, Python, Ruby, Smalltalk.
27
TDD – Technika programowania, której istota˛ jest pisanie testów przed napisaniem samego testowanego
kodu. W ten sposób definiujac
˛ testy definiuje si˛e oczekiwanie zachowanie fragmentów programu. Po samym
napisaniu testów nie maja˛ one szansy zadziałać, dopiero „dopisanie” testowanego kodu może spowodować po-
prawny przebieg testów. Takie podejście zwi˛eksza jakość tworzonego kodu – przez zapobieganie powstawaniu
w nim bł˛edów.
28
Por. z definicja˛ przedstawiona˛ we wst˛epie tej pracy.
49 / 61
Szybka integracja
Bardzo ważnym czynnikiem decydujacym

˛ o sukcesie zastosowania ciagłej
˛ integra-
cji jest czas trwania pojedynczej próby integracji poszczególnych projektów. Im krócej trwa
integracja, tym szybciej zainteresowani dostaja˛ odpowiedź, czy ostatnie zmiany nie spowodo-
wały, że aplikacja nie działa poprawnie. Im szybciej zostanie opublikowany wynik integracji,
zwłaszcza w przypadku niepowodzenia, tym szybciej i sprawniej „winni” programiści moga˛
go naprawić.
Szybkość trwania procesu budowania ma też ogromny bezpośredni wpływ na wy-
dajność programistów. Programiści podczas pracy na swoich komputerach wielokrotnie bu-
duja˛ aplikacj˛e. Oczywiście podczas uruchamiania aplikacji na swoim środowisku nie wy-
konuja˛ pełnego zakresu integracji, a jedynie te kroki, które sa˛ konieczne do skorzystania
z aplikacji. To właśnie czas trwania budowania aplikacji przekłada si˛e na ilość czasu po-
świ˛econego przez programistów na zwykłe oczekiwanie. Oczywiście nie należy tego czasu
w prosty sposób utożsamiać z czasem zmarnowanym, zwykle podczas budowania aplikacji
programista zajmuje si˛e innymi zadaniami. Natomiast sam fakt oderwania si˛e od jednej czyn-
ności i skupienia uwagi na innym zadaniu może być kosztowny czasowo. W zależności od
użytych technologii i sposobu pracy, w ciagu
˛ całego dnia pracy programista zwykle buduje
aplikacj˛e od kilku do kilkunastu razy. Jeśli pomnożyć t˛e liczb˛e przez liczebność zespołu pro-
gramistycznego, to można oszacować, ile czasu dziennie kosztuje samo budowanie aplikacji.
Dlatego warto dołożyć wszelkich starań, by optymalizować budowanie pod wzgl˛edem czaso-
wym. Każda minuta czasu budowania zyskana w ten sposób może przekładać si˛e na bardzo
wymierne efekty dla całej organizacji.
Przy analizie poj˛ecia „szybka integracja” powstaje pytanie, co oznacza „szybko”.
M. Fowler w [Fow06] postuluje by integracja trwała co najwyżej 10 minut.
Bariera ta wydaje si˛e być całkiem rozsadna
˛ dla mniejszych projektów. Natomiast dla
wi˛ekszych projektów (rz˛edu kilkuset tysi˛ecy linii kodu i wi˛ecej) spowodowanie, by cały kod
źródłowy został skompilowany, scalony, uruchomiony i przetestowany na różne sposoby w 10
minut, może być trudne – jeśli w ogóle jest możliwe. Naturalnie zawsze można próbować
wpływać na szybkość działania serwera ciagłej
˛ integracji przez inwestycje sprz˛etowe (np.
w szybszy procesor, wi˛ecej pami˛eci operacyjnej itp.), lecz w wi˛ekszości sytuacji w ten sposób
uda si˛e zyskać stosunkowo niewiele – obecnie powszechnie dost˛epny sprz˛et ma stosunkowo
dobra˛ wartość współczynnika efektu do ceny.
Przykładowe rozwiazania
˛ problemu szybkości integracji podano w rozdziale 2.3.
50 / 61
Testowanie w kopii środowiska produkcyjnego
Niezwykle ważnym elementem infrastruktury zwiazanej

˛ z ciagł
˛ a˛ integracj˛e jest śro-
dowisko (czy środowiska) testowe. Głównym zadaniem procesu integracji jest doprowadze-
nie do sytuacji, w której aplikacja działa poprawnie w środowisku testowym.
Celem wszystkich sprawdzeń jest upewnienie si˛e, że aplikacja b˛edzie działać przy
użyciu przez klienta, czyli w środowiskach produkcyjnych. Dlatego należy zadbać o to, by
sposób konfiguracji środowiska testowego był możliwie wierna˛ kopia˛ rzeczywistego środo-
wiska produkcyjnego.
[Fow06] wskazuje nast˛epujace
˛ parametry sprz˛etowo-systemowe:
• ten sam system zarzadzania

˛ baza˛ danych, w tej samej wersji,
• ta sama wersja systemu operacyjnego,
• użycie tych samych bibliotek, które b˛eda˛ używane w systemie produkcyjnym, nawet
jeśli wydaja˛ si˛e niepotrzebne,
• użycie tych samych adresów IP i portów,
• użycie takiego samego sprz˛etu.
W praktyce spełnienie wszystkich powyższych postulatów może być trudne i kosz-

towne – w szczególności organizacji dostarczajacej
˛ oprogramowanie może nie być stać na
zakup identycznych licencji, serwerów i innego sprz˛etu, co klienta. Niemniej należy sobie
zdawać spraw˛e ze wszystkich różnic wyst˛epujacych
˛ mi˛edzy środowiskami.
Działanie niektórych aplikacji polega na komunikowaniu si˛e z innymi systemami
zwykle przy użyciu jednej z usług sieciowych. Naturalnie tego typu komunikacja też po-
winna być przedmiotem testów. Problem pojawia si˛e, gdy zewn˛etrzny system nie jest nam
znany, jedynie napisano specyfikacj˛e komunikacji z nim. Ze wzgl˛edów organizacyjnych czy
finansowych może być niezmiernie trudne lub wr˛ecz niemożliwe zainstalowanie podobnego
systemu w środowisku testowym. Dlatego czasem należy uciec si˛e do tworzenia zaślepek,
które nie sa˛ w pełni działajacymi
˛ elementami, ale spełniaja˛ wymagania techniczne dotyczace
˛
komunikacji.
Przykład 8. Jeśli nasza aplikacja ma za zadanie komunikować si˛e mi˛edzy innymi

z systemem kadrowo-płacowym zainstalowanym u klienta, a nie jest możliwe zainstalowanie
takiego samego systemu w środowisku testowym, warto stworzyć zaślepk˛e takiego systemu.
51 / 61
Odpowiadałaby ona na zapytania w sposób możliwie poprawny składniowo (spełniajac

˛ wy-
magania interfejsu), bez dochowywania wierności i spójności danych. Nie musi to być pełna
implementacja systemu kadrowo-płacowego.
Na rynku dost˛epnych jest wiele narz˛edzi, których celem jest tworzenie zaślepek
do różnego typu usług sieciowych, co pozwala wybrnać
˛ z trudnej sytuacji przy zestawianiu
środowiska testowego.
Udost˛epnienie najnowszej wersji aplikacji gotowej do uruchomienia
Przydatnym efektem zastosowania środowiska ciagłej

˛ integracji w organizacji jest
udost˛epnianie najnowszej działajacej
˛ wersji aplikacji. Po pierwsze, niejako efektem ubocz-
nym procedury integracji jest uruchomienie aplikacji na serwerze testowym. Po drugie, wi˛ek-
szość serwerów ciagłej
˛ integracji udost˛epnia gotowa˛ do użycia wersj˛e aplikacji jako jeden
z produktów integracji.
Dzi˛eki temu w każdej chwili można bez problemu pobrać taka˛ aplikacj˛e i urucho-
mić w innym środowisku. Umożliwia to obserwowanie post˛epu prac w projekcie przez osoby
spoza zespołu czy demonstrowanie aplikacji klientowi. Taka możliwość przydaje si˛e w pro-
cesie wst˛epnego zbierania uwag od przyszłych użytkowników systemu, co z kolei przybliża
dostawc˛e oprogramowania do celu, jakim jest satysfakcja klienta. Ogólnie, ciagłe
˛ udost˛epnia-
nie najnowszej wersji aplikacji klientowi byłoby krokiem odważnym, ale wartym rozważenia
w projektach prowadzonych metodykami zwinnymi.
2.3 Skalowalność
Jak napisano w rozdziale 2.2, istotnym dla skutecznego działania ciagłej
˛ integracji
w projekcie jest sprawne działanie serwera.
Z jednej strony da˛ży si˛e do skracania jak to tylko możliwe czasu pojedynczej próby
integracji. Głównie po to, by odpowiedź o stanie aplikacji po wgraniu kodu do repozytorium
przychodziła do zainteresowanych członków zespołu jak najszybciej. Jednakowoż długi czas
trwania prób budowania poszczególnych aplikacji przekłada si˛e na gorsza˛ wydajność całego
środowiska ciagłej
˛ integracji, a im sprawniej przebiega integracja, tym cz˛eściej można jej
próbować.
Przeciwstawnym da˛żeniem jest tendencja do rozbudowywania zestawu testów tak,
by aplikacje były sprawdzane w coraz dokładniejszy sposób. Im wi˛ecej różnych sposobów,
52 / 61
na które program jest sprawdzany, tym wi˛eksza pewność co do jego jakości. W naturalny
sposób gruntowne inspekcje prowadza˛ jednak do wydłużenia czasu integracji.
Chcac
˛ pogodzić obie tendencje można spróbować nast˛epujacych,
˛ zupełnie różnych,
rozwiazań:
˛
• klaster serwerów ciagłej

˛ integracji, czyli złaczenie
˛ sił wielu komputerów w celu zbu-
dowania środowiska ciagłej
˛ integracji,
• integracja etapowa – pewien sposób oszcz˛edzenia czasu integracji przez sekwencyjne

wykonywanie poszczególnych etapów integracji.
Oba podejścia zostały opisane w nast˛epnych podrozdziałach.
2.3.1 Klaster serwerów ciagłej

˛ integracji
W dobie stosunkowo taniego sprz˛etu elektronicznego, w tym komputerów osobi-

stych, niedużym kosztem nawet dla małych organizacji jest kupno drugiego lub kilku kom-
puterów. Pozwala to uniknać
˛ konieczności zakupu specjalistycznych serwerów, które nie sa˛
tanie.
Klaster komputerowy polega na takim połaczeniu

˛ wielu komputerów, by realizo-
wały wspólny cel. Połaczenia
˛ dokonywać można na różnych poziomach – w szczególności
w sposób niewidoczny lub widoczny dla aplikacji. Pierwsze podejście jest ogólne i w swoim
założeniu nie wymaga ingerencji w sposób działania aplikacji, przez co staje si˛e niewartym
uwagi w niniejszej pracy. Drugie podejście opiera si˛e na zmianie działania klastrowanej apli-
kacji tak, by prowadziła wymian˛e informacji w sieci złożonej z wielu w˛ezłów.
W klastrowaniu oprogramowania ciagłej

˛ integracji stosuje si˛e zwykle jeden w˛ezeł
główny i wiele tak zwanych agentów – programów b˛edacymi
˛ „klientami” serwera ciagłej
˛
integracji (jak zobrazowano na poniższym rysunku).
53 / 61
Rysunek 2.5: Infrastruktura rozproszonego środowiska ciagłej

˛ integracji.
Podstawowymi zadaniami w˛ezła głównego sa:

˛
• zlecanie prób integracji agentom,
• komunikacja z użytkownikami, w tym prezentowanie stanu środowiska ciagłej

˛ integra-
cji.
Agenty oczekuja˛ na komunikaty od w˛ezła głównego i po otrzymaniu zlecenia do-

konuja˛ próby integracji zadanego projektu. Nast˛epnie przesyłaja˛ wynik integracji do w˛ezła
głównego – w tym informacj˛e o tym, czy próba si˛e powiodła, oraz wszystkie produkty inte-
gracji.
W najprostszym podejściu instaluje si˛e kilka (lub wi˛ecej) agentów działajacych
˛ w
takim samym środowisku. Jednakże niektóre z produktów ciagłej
˛ integracji przystosowane
sa˛ do zarzadzania
˛ wieloma różnymi agentami; w takim podejściu nie wszystkie z agentów sa˛
identyczne. O ile testowanie w różnych wersjach tego samego oprogramowania czy w róż-
nych przegladarkach
˛ internetowych nie wymaga zwykle różnorodnych agentów29 , to w sytu-
acji, w której chcemy testować aplikacj˛e w różnych systemach operacyjnych czy na różnych
29
Każdy z agentów jest w stanie testować aplikacj˛e z użyciem różnych przegladarek
˛ zainstalowanych na
tym samym komputerze.
54 / 61
platformach sprz˛etowych niezb˛edne jest skonstruowanie zestawu niejednorodnych agentów.

Jeśli zespół programistyczny ma na celu tworzenie aplikacji działajacej
˛ zarówno w syste-
mach Microsoft Windows, Mac OS X i jakiejś odmianie Uniksa, najpewniejszym wydaje si˛e
posiadanie co najmniej trzech różnych serwerów. Na każdym z nich zainstalowano by inny
system operacyjny i co najmniej jednego agenta podłaczonego
˛ do w˛ezła głównego. Każdy
z trzech agentów byłby odpowiedzialny za budowanie na swoim systemie operacyjnym.
Naturalnie cz˛esto stosuje si˛e instalowanie kilku agentów działajacych
˛ na jednym
serwerze, co przynosi szczególne korzyści przy wykorzystaniu serwerów w wielordzeniowy-
mi procesorami. Warto wtedy zainstalować co najmniej tyle agentów, co rdzeni procesora.
W zależności od charakteru aplikacji i jej integracji, zasadnym wydaje si˛e rozważenie nawet
wi˛ekszej liczby agentów – jeśli tylko moc obliczeniowa procesora nie jest waskim
˛ gardłem.
W pewnych zastosowaniach przydaje si˛e inna cecha rozproszonych środowisk cia-
˛
głej integracji– mianowicie możliwość dynamicznego odłaczania
˛ i dołaczania
˛ agentów. Wy-
korzystanie takiej funkcjonalności może służyć do optymalizacji mocy obliczeniowych kom-
puterów dost˛epnych w organizacji. Jeśli dost˛epne sa˛ komputery, które wykonuja˛ inne zadania
tylko przez pewien czas, a przez pozostały czas stoja˛ bezczynnie, warto zaprzac
˛ je do pracy
w ciagłej
˛ integracji. Konfiguruje si˛e wtedy agenty ciagłej
˛ integracji działajace
˛ tylko w okre-
ślonych ramach czasowych.
Przykładem implementacji środowiska ciagłej
˛ integracji, która została zaprojekto-
wana z myśla˛ o rozproszonym przetwarzaniu przez wiele agentów, jest TeamCity (szerzej
opisana w rozdziale 2.1). Podatność na skalowalność wydaje si˛e być ważna˛ cecha˛ środowisk
ciagłej
˛ integracji – zwłaszcza w organizacjach, które tworza˛ co najmniej kilka skomplikowa-
nych produktów.
W nurt rozwiazań
˛ ciagłej
˛ integracji wpisuje si˛e niezwykle modne ostatnio poj˛ecie
ang. cloud computing30 . Przykładem programu z rynku ciagłej
˛ integracji i działajacego
˛ zgod-
nie z koncepcja˛ cloud computing – gotowego do użycia z Amazon EC231 – jest Bamboo,
produkt firmy Atlassian32 . Bamboo dostarcza trzy rodzaje agentów:
30
W opinii autora niniejszej pracy brak jest dobrego tłumaczenia na polski. Sugerowane przez niektórych
„przetwarzanie w chmurze” nie wydaje si˛e odpowiednie.
31
EC2 – pełna nazwa Amazon Elastic Compute Cloud – sieciowa usługa wynajmu wirtualnych kompute-
rów. Ostatnio szybko zyskuje na popularności, reklamowana jako rewolucja w dziedzinie zarzadzania
˛ zasobami
serwerowymi w firmie.
32
Najbardziej znanym produktem tej australijskiej firmy jest JIRA – narz˛edzie do śledzenia zadań, bł˛edów
itp.
55 / 61
• lokalny agent – uruchamia prób˛e integracji na tej samej maszynie co serwer ciagłej
˛
integracji,
• zdalny agent – uruchamia prób˛e integracji na innym komputerze,
• elastyczny agent – uruchamia prób˛e integracji w wirtualnym serwerze działajacym

˛
w chmurze Amazon EC2.
Jak każde zastosowanie cloud computing, również cloud computing w służbie ciagłej
˛ inte-
gracji pokazuje, że do dokonywania dużych obliczeń wcale nie sa˛ konieczne duże inwestycje
w sprz˛et. Co wi˛ecej, zastosowanie tego pomysłu pozwala na dynamiczne decydowanie o ilo-
ści mocy obliczeniowej poświ˛econej na ciagł
˛ a˛ integracj˛e i płacenie tylko za wykonana˛ prac˛e.
2.3.2 Budowanie etapowe

Odmienna˛ strategia˛ organizacji pracy środowiska ciagłej
˛ integracji jest budowanie
etapowe – ang. stage building. Polega ono na rozbiciu procesu integracji projektu na kilka
procesów wykonywanych sekwencyjnie. Tak wi˛ec ciag
˛ operacji wykonywanych w obr˛ebie
jednej próby integracji zmienia si˛e w ciag
˛ prób integracji zależnych od siebie. Pomysł opiera
si˛e na spostrzeżeniu, że niektóre z rodzajów testów moga˛ być czasochłonne, można je wtedy
wydzielić do osobnego procesu.
Takie założenie umożliwia wykonywanie tylko cz˛eści ze sprawdzeń na bieżaco
˛ (po
każdym wgraniu kodu do repozytorium), a pozostałych – rzadziej (co kilka godzin, co noc
itp.). Takie postawienie sprawy pozwala zaoszcz˛edzić troch˛e mocy obliczeniowych serwe-
ra ciagłej
˛ integracji, co może być konieczne, jeśli serwer pracuje cały czas pełnia˛ swoich
możliwości, a postawione cele ilościowe co do cz˛estości prób integracji nie sa˛ spełnione.
Nie należy zapominać, że przy takim podejściu rezygnuje si˛e w pewnym stopniu z kontroli
jakości tworzonego oprogramowania – wszak uznaje si˛e niektóre próby integracji za pomyśl-
ne, mimo że nie wykonano wszystkich sprawdzeń. Ocena sensowności takiego post˛epowania
zależy od specyfiki projektu i leży w gestii zarzadzaj
˛ acych
˛ projektem.
Kolejnym zastosowaniem tej idei może być testowanie aplikacji w odmiennych śro-
dowiskach. Można wtedy wydzielić cz˛eść wspólna˛ integracji dla różnych konfiguracji – np.
pobieranie źródeł, kompilacj˛e, testowanie jednostkowe i statyczna˛ analiz˛e kodu jako jeden
etap integracji. Nast˛epnie trzeba zdefiniować kilka etapów, których przebieg jest identycz-
ny i zawiera dalsze kroki integracji – np. uruchomienie i testowanie uruchomionej aplikacji.
Każdy z tych etapów polegałby na tych samych czynnościach, ale wykonywanych w innych
konfiguracjach – np. z użyciem innego serwera aplikacyjnego. Wydaje si˛e to oszcz˛ednościa˛
56 / 61
czasu w porównywaniu z podejściem, w którym cały proces jest powtarzany w odmiennych

konfiguracjach, włacznie
˛ z krokami, które nie zależa˛ od tej konfiguracji.
57 / 61
Zakończenie
Ocena przydatności ciagłej

˛ integracji
W pracy zaprezentowano ciagł

˛ a˛ integracj˛e, jej rol˛e i wartość, jaka˛ może wnieść do
procesu wytwarzania oprogramowania. Niewatpliwie
˛ jej zastosowanie przynosi korzyści (jak
opisano w rozdziale 1.5), jednak wymaga poniesienia pewnych kosztów (patrz rozdział 1.6).
Niemniej ciagła
˛ integracja pozostaje ciekawa˛ propozycja,˛ zwłaszcza w projektach kierowa-
nych metodykami zwinnymi.
Praca [Min09] przedstawia ciekawa˛ propozycj˛e modelu dojrzałości ciagłej

˛ integra-
cji. Autor proponuje pi˛eć stopni zaawansowania wdrożenia ciagłej
˛ integracji w projektach
informatycznych: od poziomu wst˛epnego (kiedy jest używane repozytorium kodu i automat
buduje aplikacj˛e w rytmie tzw. nocnych wydań) do poziomu „szalonego”33 (w którym środo-
wisko ciagłej
˛ integracji na bieżaco
˛ wgrywa nowa˛ wersj˛e aplikacji do środowiska produkcyj-
nego).
Propozycja jest o tyle ciekawa, że dowodzi przydatności ciagłej

˛ integracji w różnych
zastosowaniach – o różnej skali komplikacji, a także o różnym stopniu uzależnienia procesu
tworzenia oprogramowania od ciagłej
˛ integracji.
Bez watpienia
˛ ciagła
˛ integracja, jeśli tylko b˛edzie poprawnie stosowana, może być
przydatna w wi˛ekszości projektów programistycznych. Sama lektura różnych koncepcji po-
stulowanych przez zwolenników ciagłej
˛ integracji może być inspirujaca
˛ i wspomóc nadzoro-
wanie jakości w projektach informatycznych.
33
Ang. insane.
58 / 61
Potencjalne kierunki dalszych analiz

Niewatpliwie
˛ ciagła
˛ integracja jest ciekawa˛ koncepcja,˛ która wspiera rozwój opro-
gramowania. Stanowi dodatkowy mechanizm kontrolny, wspomaga sprawdzanie jakości, do-
starcza narz˛edzie do śledzenia post˛epu prac projektowych. Najlepsze zastosowanie znajduje
w projektach prowadzonych metodykami zwinnymi, jednak stosowana w przedsi˛ewzi˛eciach
prowadzonych innymi metodami również stanowi pewna˛ wartość.
Popularność
Ciagła
˛ integracja wydaje si˛e być dobrym pomysłem, jednym z kilku prostych na-
rz˛edzi, które moga˛ dużo wnieść do projektu informatycznego. Tym bardziej intrygujaca
˛ jest
niezbyt duża popularność tego podejścia. Co prawda niektóre badania wskazuja˛ na ogromna˛
popularność34 tego zjawiska, ale nie wydaja˛ si˛e one wiarygodne. Bliższa prawdy zdaje si˛e być
ankieta35 przeprowadzona w marcu 2009 na stronie jdn.pl (tak wi˛ec w polskim środowisku),
której wyniki przedstawiono w poniższej tabeli:
Jak wyglada
˛ ciagła
˛ integracja (CI) w twoim projekcie?
nie wiem o co chodzi 32% (43 głosy)
nie mamy odpowiedniego narz˛edzia 12% (16 głosów)
nie działa, bo nie ma testów 15% (20 głosów)
jest, ale nikogo to nie obchodzi 19% (25 głosów)
jest, kto zepsuje build musi odbyć kar˛e 17% (22 głosy)
jest, zespół jest rozliczany z ilości zepsutych buildów 5% (7 głosów)
Tabela 2.2: Wyniki ankiety popularności ciagłej

˛ integracji.
Źródło: http://jdn.pl/node/1733.
Nie należy przywiazywać

˛ wi˛ekszej wagi do tych wyników, jednak z pewnościa˛
wskazuja˛ one, że nawet jeśli idea ciagłej
˛ integracji jest znana, nie jest stosowana z pożytkiem.
Zaliczajac
˛ nawet dwie ostatnie odpowiedzi jako pozytywne, wyniki ankiety każa˛ sadzić,
˛ że
ciagła
˛ integracja jest stosowana tylko w 21% projektów. Nawet taki wskaźnik, choć mało
prawdopodobny, przedstawia ciagł
˛ a˛ integracj˛e jako narz˛edzie niszowe.
Powstaje pytanie, dlaczego koncepcja ciagłej
˛ integracji nie zyskała sobie znacznej
popularności. Pozostaje w pewien sposób nieprzyj˛etym szeroko rozwiazaniem.
˛ Wydaje si˛e to
34
Badania przedstawione w [Fle09] wykazuja˛ 90,8% projektów stosujacych
˛ ciagł
˛ a˛ integracj˛e.
35
Patrz http://jdn.pl/node/1733.
59 / 61
być dobrym tematem do dalszych badań. Ciekawym wynikiem byłyby informacje, co przy-
ciaga,
˛ a co zraża do stosowania ciagłej
˛ integracji? Co stoi na przeszkodzie wi˛ekszej popular-
ności ciagłej
˛ integracji?
Podejścia do automatycznego testowania
Poza obszar tej pracy wykraczaja˛ również rozważania na temat sposobu automaty-
zacji testów. Wydaje si˛e, że w dobie powszechnie dost˛epnych dużych mocy obliczeniowych
i w czasach szybkiej wymiany idei istnieje wiele różnych ciekawych i przydatnych koncepcji
automatycznego testowania aplikacji.
Testować można m.in.:
• różne warstwy aplikacji,
• jednostkowo lub całościowo,
• w sposób deterministyczny i z doza˛ losowości,
• pod katem
˛ poprawności działania, szybkości, wydajności itp.
Interesujaca
˛ byłaby analiza poszczególnych rodzajów automatycznych testów apli-
kacji komputerowych – w szczególności ich zastosowań, ograniczeń, korzyści jakie moga˛
nieść, wskazań, kiedy i w jakich projektach moga˛ być szczególnie przydatne.
60 / 61
Bibliografia
[Duv07] Paul Duvall. Automation for the people: Continuous integration anti-patterns.
http://download.boulder.ibm.com/ibmdl/pub/software/dw/java/j-ap11297-pdf.pdf,
2007.
[Fle09] Georg Fleischer. Continuous integration. what companies expect and solutions
provide. http://appl.fontysvenlo.org/results/2008/GF/continuous_integration.pdf,
2009.
[Fow06] Martin Fowler. Continuous integration. http://martinfowler.com/articles/
continuousIntegration.html, 2006.
[Man01] Manifesto for agile software development. http://agilemanifesto.org, 2001.
[mat] Ci feature matrix. http://confluence.public.thoughtworks.org/display/CC/
CI+Feature+Matrix.
[Min08] Eric Minick. Continuous integration: Was fowler wrong?
http://www.anthillpro.com/blogs/anthillpro-blog/2008/07/14/
continuous_integration_was_fowler_wrong.html, 2008.
[Min09] Eric Minick. Continuous integration maturity mo-
del. http://www.anthillpro.com/blogs/anthillpro-blog/2009/05/05/
continuous_integration_maturity_model.html, 2009.
[PD07] Andrew Glover Paul Duvall, Steve Matyas. Continuous Integration: Improving
Software Quality and Reducing Risk. Addison-Wesley, 2007.
[Sav04] Alberto Savoia. Extreme feedback for software development.
http://www.developertesting.com/archives/month200404/20040401-
eXtremeFeedbackForSoftwareDevelopment.html, 2004.
[Sub04] Venkat Subramaniam. Test driven development – part iii: Continuous integration.
http://www.agiledeveloper.com/articles/TDDPartIII.pdf, 2004.
61 / 61

Praca Dyplomowa: Środowiska Ciągłej Integracji W Wytwarzaniu Oprogramowania

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Praca Dyplomowa: Środowiska Ciągłej Integracji W Wytwarzaniu Oprogramowania

Uploaded by

Copyright:

Available Formats

POLITECHNIKA WARSZAWSKA

Rok. akad. 2008/2009

TEMAT PRACY DYPLOMOWEJ:

Termin wykonania: sierpień 2009

CONTINUOUS INTEGRATION ENVIRONMENTS

Continuous integration is a software development technique gaining in popularity,

1 Analiza środowisk ciagłej

2 Praktyka wykorzystania ciagłej

Cel i zakres pracy

Celem pracy jest przybliżenie poj˛ecia „ciagłej

Integracja w procesie produkcji oprogramowania

Poj˛ecia „integracji” czy „budowania” w kontekście procesu produkcji oprogramo-

W projektach prowadzonych zgodnie z tradycyjnymi metodykami integracja jest

• Integracja jest długotrwałym procesem. W zależności od liczności zespołu, stopnia

praktyk˛e w projektach informatycznych polegajac

Jest to w zasadzie najpopularniejsza definicja poj˛ecia, przyjmowana w miar˛e zgod-

Jak można zauważyć, choćby przygladaj

• wymaga poniesienia pewnych nakładów czy inwestycji organizacyjnych,

• nadaje si˛e do zastosowania w różnych projektach wytwarzania oprogramowania.

Analiza środowisk ciagłej

1.1 Schemat interakcji w środowisku ciagłej

• użytkownicy – najcz˛eściej programiści, ale również inni współtworzacy

• repozytorium kodu – miejsce składowania kodu źródłowego aplikacji, system kontroli

Rysunek 1.1: Schemat interakcji w środowisku ciagłej

Istnieja˛ co najmniej dwa główne podejścia do tego, kiedy serwer ciagłej

• Według harmonogramu. W najprostszym podejściu dla każdego z projektów zarza-

• Przy każdej zmianie kodu w repozytorium. W tym podejściu podczas wgrywania

Wi˛ekszość serwerów ciagłej

Dodatkowo serwery ciagłej

1.2 Warunki zastosowania ciagłej

• monitorowanie stanu aplikacji i reagowanie na dłuższe pozostawanie aplikacji w stanie

• przydzielanie poszczególnym członkom zespołu zadań naprawy bł˛edów wykrytych

Szczegółowy zakres zadań osoby nadzorujacej

1.3 Możliwości środowisk ciagłej

• odświeżanie kodu źródłowego i innych danych wejściowych integracji,

• podj˛ecie decyzji o zasadności kontynuowania integracji,

• testowanie i mierzenie stopnia pokrycia kodu testami,

• statyczna analiza kodu i automatyczny przeglad

• umieszczenie i uruchomienie (ang. deployment) aplikacji w środowisku testowym,

• testowanie aplikacji uruchomionej w środowisku testowym,

• zapisanie wyniku integracji i powiadomienie o nim użytkowników,

• (w przypadku pomyślnego przejścia poprzednich wszystkich kroków) oznaczenie kodu

Oczywiście nie jest to lista wyczerpujaca.

Rysunek 1.2: Przykładowy przebieg integracji.

1.3.1 Odświeżanie kodu źródłowego

1.3.2 Decyzja o zasadności kontynuowania integracji

Jak wynika z powyższych przykładów, cz˛esto konfiguruje si˛e serwer ciagłej

Przykład 1. W technologii JEE proces budowania najcz˛eściej ma na celu wypro-

Przykład 3. Z kolei proces budowania w projekcie biblioteki komponentów wizu-

W konsekwencji wszelkie scenariusze r˛ecznych testów nie znajduja˛ zastosowania

Ze wzgl˛edu na powyższe uwarunkowania automatyczne testy aplikacji powinny sta-

Wszelkie testy niewymagajace

Produktem testowania jest raport z testów. Wi˛ekszość narz˛edzi automatycznego te-

Rysunek 1.3: Przykładowy raport z testów narz˛edzia JUnit.

Pokrycie kodu testami

niewielka wartość tego wskaźnika – informuje o niepewności testów, co z punktu widzenia

Najważniejsza informacja w powyższym widoku to współczynnik pokrycia wyno-

• histogram współczynnika pokrycia kodu poszczególnych klas,

• wykres zależności mi˛edzy złożonościa˛ klasy a pokryciem testami,

• diagram najbardziej złożonych pakietów i ich współczynników pokrycia,

• 100% pozytywny wynik wykonanych testów,

• list˛e najmniej przetestowanych metod.

Rysunek 1.5: Wycinek raportu narz˛edzia Clover opisujacy