blog.testowka.pl

Continuous integration – i po co to wszystko?

opublikowany przez 19, Sty, 2010, w kategoriach Agile, Automatyzacja, CI

Na wstępie chciałbym w skrócie przedstawić podstawowe zasady CI, a może raczej ACI (Automated Continuous Integration):

Trzymaj kod w repozytorium
A nawet nie tyle trzymaj co commituj swoje zmiany jak najczęściej, dzięki temu każdy będzie miał możliwość integrowania swoich zmian z Twoimi. Do tego należy także pamiętać o tym aby także updateować jak najczęściej swoje lokalne repozytorium na którym się pracuje aby integrować swoje zmiany z najświeższymi zmianami kolegów.
Cechy dobrego repozytorium to przede wszystkim:
– przejrzysty widok ostatnich zmian
– możliwość tworzenia rozgałęzień i automatycznego łączenia ich
– system powiadomień o zmianach
– łatwa możliwość odwrócenia ostatnich zmian
Osobiście używam GIT i SVN, jak na razie obydwa spełniają większość moich oczekiwań.

Automatyzuj buildy
Buildy powinny być odpalane automatycznie. Do automatyzacji buildów polecam Hudson lub CruiseControll. Warto też wspomnieć o tym co taki build powinien robić, mianowicie powinien:
– odpalać testy jednostkowe
– odpalać inne testy (jeśli są)
– generować raporty z pokrycia kodu testami
– generować raporty z wynikami testów
– wysyłać powiadomienia, zwłaszcza gdy testy nie przechodzą
– powinien być zintegrowany ze środowiskiem RC do którego commity powinny trafiać jedynie, gdy build przechodzi
– powinien generować inne artefakty, które są w danym projekcie potrzebne.

Stosuj TDD
Tak, by to wszystko miało sens potrzebne są testy do kodu, który piszemy. Jak najwięcej testów. Najlepszą praktyką w tej dziedzinie jest TDD – pisanie testów przed napisanie właściwego kodu (ale o tym może innym razem).

Zasada nie zabierania zakiszonego kodu do domu
Każdy programista commituje przynajmniej raz dziennie. Im częściej tym lepiej.

Każdy commit odpala build
Po każdej zmianie kodu powinny być odpalane testy w celu jak najszybszego wykrycia błędów i ich poprawy,a także w celu łatwiejszego wykrycia przyczyny błędu (zazwyczaj należy jej szukać tylko w ostatnim commicie).

Utrzymuj build szybkim
Buildy powinny być jak najszybsze, by niepotrzebnie nie marnować czasu na czekanie, aż build przejdzie. Obecnie rozwiązuje się ten problem w sposób sprzętowy np stosując chmury obliczeniowe do odpalania testów.

Środowisko testowe powinno być bliźniacze do środowiska produkcyjnego
Chociażby dlatego by uniknąć błędów wynikających z różnicy w tych środowiskach.

W każdej chwili powinieneś mieć dostęp do ostatniej stabilnej wersji oprogramowania
Zgodnie ze wspomnianą zasadą Agile, w każdej chwili powinniśmy mieć pod ręką jakąś stabilną wersję oprogramowania teoretycznie gotową do publikacji.

Każdy powinien mieć dostęp do wyników buildów
Na przykład Hudson ma wbudowany ciekawy plugin, który umożliwia graficzna prezentację wyników ostatnich buildów. Tego typu aplikacje mają zazwyczaj także api, które sprzyja tworzeniu własnych rozwiązań do prezentacji efektów testów etc. My w firmie używamy właśnie Hudsona i specjalnego monitora który stojąc w widocznym dla każdego miejscu prezentuje efekty ostatnich commitów.

Automatyczny deployment
Fajny ficzer zwłaszcza w fazie maintenance projektu, gdy zmiany są dosyć często wgrywane na serwer produkcyjny. Istnieją gotowe narzędzia pozwalające na automatyczne deployowanie aplikacji.

Żeby lepiej zrozumieć na czym polega CI należało by się pierw zastanowić po co właściwie coś takiego jak Ciągła Integracja jest nam potrzebne? Najprościej będzie gdy wrócimy do jednego z podstawowych założeń zwinnego zarządzania projektami a mianowicie: „w dowolnym (odpowiednio zaawansowanym) momencie trwania projektu powinniśmy być w stanie dostarczyć ‚jakiś’ produkt, który spełnia pewne założenia i udostępnia pewną funkcjonalność, produkt ten teoretycznie powinien być gotowy do wypuszczenia na rynek”. Idąc dalej tym tropem można łatwo wywnioskować, że aby produkt był gotowy do publikacji musi spełniać pewne kryteria jakości, które powinny zostać przetestowane. By jeszcze lepiej zrozumieć potrzebę ciągłej integracji w projekcie należałoby się zastanowić nad tym w jaki sposób integrować pracę wielu programistów, którzy pracują nad często zazębiającymi się fragmentami kodu. Może aby lepiej zobrazować strukturę problemu posłużę się przykładem w którym zespół projektowy nie wykorzystuje aspektów CI.

Wyobraźmy sobie zespół składający się z pięciorga programistów i dwojga testerów. Zespół ma dostarczyć jakąś określoną aplikację, która ma trzy podstawowe funkcjonalności. Tutaj pojawia się pierwszy problem – jak podzielić pracę? Może niech każdy programista zajmie się pojedynczą funkcjonalnością, a na koniec spróbują zintegrować to wszystko ze sobą (uwierzcie mi są firmy w których taki model wytwarzania oprogramowania jest stosowany na co dzień). No tak tylko, że funkcjonalności jest 3 a programistów pięcioro. Poza tym są jeszcze testerzy, którzy przez większość czasu będą się nudzić. No dobrze – klasyczny model Waterfall zakłada, że testy powinny być przeprowadzane na końcu, więc niech tak będzie. Żeby jeszcze lepiej wszystko zobrazować dodajmy trochę matematyki. Załóżmy, że wykonanie pierwszej funkcjonalności zajmie około 30 roboczogodzin, drugiej 60 roboczogodzin, trzeciej 15 roboczogodzin. Do tego przetestowanie około 1/3 czasu potrzebnego na implementację czyli odpowiednio 10, 20, 5 roboczogodzin (dość optymistyczne, ale realne założenia). Dobrze – prace ruszyły pierwsza po 15 godzinach zostaje ukończona funkcjonalność nr 3, programista który nad nią pracował teraz odpoczywa. Po kolejnych 15 godzinach została ukończona funkcjonalność nr 1, teraz programiści mogą rozpocząć prace nad integracją funkcjonalności 1 i 3, mają na to około 30 godzin. Po 60 godzinach od rozpoczęcia projektu dostarczono funkcjonalność nr 2, którą teraz trzeba jeszcze zintegrować, na tym etapie okazuje się że popełniono kilka błędów w założeniach, czegoś nie ustalono dokładnie etc. wiec integracja potrwa kolejne 20h. W sumie po 80 godzinach pracy dostarczono produkt do testów. Testowanie wraz z poprawkami zajmie około 40h.

Po 120 godzinach pracy mamy gotowy produkt. Przypomnijmy, że dla dwóch programistów nie było pracy, ciężko jest pracować nad jednym kawałkiem kodu na dwóch różnych komputerach. Co najwyżej służyli oni jedynie pomocą swoim kolegom.

A teraz podobny przykład (ten sam problem do rozwiązania) z tym że zespół wykorzysta większość aspektów CI.

Ponieważ wiemy ile szacunkowo zajmą pracę nad każdą z funkcjonalności i wiemy, że funkcjonalność nr 2 zajmie najdłużej pracować nad nią będzie aż troje programistów, dodatkowo programista, który będzie pracował nad funkcjonalnością nr 3 po zakończeniu prac nad nią wesprze kolegę pracującego nad funkcjonalności nr 1. Praca zespołowa jest w pełni możliwa dzięki temu, że zespół korzysta z systemu kontroli wersji, który pozwala na łatwą dystrybucję najaktualniejszego kodu. Dodatkowo testerzy dzięki środowisku, które roboczo nazwiemy RC (Release Candidate) mogą w każdej chwili testować dostarczane funkcjonalności i zgłaszać błędy, które są dużo łatwiejsze do poprawienie we wcześniejszej fazie. Należy też zauważyć, że integracja całości odbywa się od samego początku, gdyż wszystkie zmiany wrzucane są do jednego repozytorium. Czas implementacji wydłuży się zapewne o około 1/3 ze względu konieczność pisania testów jednostkowych (nie jest to wymóg jeśli w zespole są testerzy, jednak dzięki temu ich praca powinna się skrócić o około połowę). Zobaczmy jak to teraz wygląda. Planowane czasy implementacji po uwzględnieniu dodatkowego pisania testów jednostkowych: F1 – 40 roboczogodzin, F2 – 80 roboczogodzin, F3 – 20 roboczogodzin. Testy: T(F1) – 7 roboczogodzin, T(F2) – 14 roboczogodzin, T(F3) – 4 roboczogodziny. Projekt startuje. Po 10 godzinach pracy rozpoczynają się testy dla funkcjonalności nr 2 (wykonuje je jeden tester). Po 16 godzinach od rozpoczęcia rozpoczynają się testy akceptacyjne dla funkcjonalności nr 3, po 20 godzinach od rozpoczęcia ta funkcjonalność jest już gotowa i przetestowana, programista, który nad nią pracował pomaga programiście pracującemu nad funkcjonalnością nr 1 (do jej ukończenia zostało 20 roboczogodzin, podzielone na dwóch daje po 10 godzin). Trzy godziny później rozpoczynają się testy funkcjonalności nr 1. Po kolejnych 7 godzinach funkcjonalność nr 1 jest ukończona i przetestowana – minęło 30 godzin od rozpoczęcia projektu. W międzyczasie po około 27 godzinach od rozpoczęcia projektu zostaje ukończona i przetestowana funkcjonalność nr 2. Wszystko powinno działać i być już zintegrowane, dla pewności testerzy sprawdzą wszystko jeszcze raz – po 8 godzin każdy.

W sumie daje nam to 38 godzin pracy nad projektem, których efektem jest gotowy, przetestowany produkt, którego dodatkowym gwarantem jakości są test jednostkowe. Dodatkowo od pewnego momentu w z środowiska RC mogliśmy pobrać stabilną – przetestowaną wersję aplikacji zapewniającą pewne funkcjonalności. To raczej znacznie lepszy wynik niż poprzednio. Powyższe założenia są trochę naciągane i wyssane z palca, ale uwierzcie mi już kilkukrotnie widziałem nawet dużo bardziej zaskakujące efekty wprowadzenia CI do procesu wytwarzania oprogramowania.

Powyższy wywód jest również pewnego rodzaju odpowiedzią na często stawiane pytanie: „Czy pisać testy jednostkowe?”. Postaram się w przyszłości poszukać (być może samemu przeprowadzić) jakichś badań na temat czasu wytwarzania oprogramowania z i bez. Ogólnie już teraz mogę wnioskując z doświadczenia jednoznacznie stwierdzić, że niemal zawsze automatyzacja testów znacząco przyspiesza pracę nad projektem, a zwłaszcza pracę w fazie maintenance.


5 Comments for this entry

  • Wiking

    Fajnie napisane – brakuje jednak mi jednozdaniowego podsumowania: „CI lepiej zapobiegac powstawaniu bledow niz je pozniej naprawiac” Dzieki CI unikamy wielu bledow poprzez natychmiastowe informacje Programista1 – twoj kod powoduje konflikt podczas commit, Programista2 – po dodaniu twoich zmian kod sie nie kompiluje itd…

    Proces CI ma to do siebie ze mozna go zmodyfikowac i stowrzyc taki ktory ma maksymalnie ulatwic prace jak i podniesc jaskosc.

    np:
    – commit
    – build
    – publikuj artefakty
    – weryfikacja poprawnosci kodu
    – deploy
    – automatyczne testy funkcjonalne
    – automatyczne testy wydajnosciowe

    Ostanie 2 punkty realizowane sa juz po wystawieniu wer na server testowy. Testy mozna planowac i np. podzielic funkcjonalne na Sanity check oraz wszystkie, a w przypadku testow wydajnosciowych w zaleznosci od rodzaju testu mozna ustawic kiedy ma byc uruchamiany.

  • Tommy

    Fajnie napisane pomimo lekko nierzeczywistej realizacji – bez uwzględnienia czasu na naprawę błędów i powtórne testy.
    Ale właśnie możliwość szybkiej weryfikacji poprawek błędów jest wielkim plusem CI.

  • Gall Anonim

    Z mojej strony tylko taka drobna uwaga:

    Jest drobny błąd w tytule i treści artykułu – „Continous integration”, a powinno być „Continuous integration”, brakuje jednego „u” ;).

  • streser

    Dziękuję!

    BTW: To niesamowite, że ktoś czyta posty z przed pięciu lat! To daje niezłego motywacyjnego kopa do dalszego pisania i opłacania abonamentu za domenę 😉

  • Sytams

    Pracuję obecnie jako tester przy dużym globalnym projekcie w dużej firmie i postanowiłem się podszkolić z tego tematu i zacząłem od kilku dni czytać Twój blog jako właśnie doinformowania się w tym temacie.

    Lecę od początku bo wierzę, że warto 🙂

    pozdrawiam

Skomentuj