Continuous Integration – po co mi to?

Gdzie projekt w którym jest więcej niż jeden programista, tam Continuous Integration jest nieodzowne. Zaryzykuję nawet stwierdzenie, że nawet jak jest jeden programista – to jest potrzebne. Jeśli nie zastosujemy automatycznego budowania projektu, to trudno będzie utrzymać dyscyplinę – ktoś w końcu zapomnij odpalić testy czy trzymać się standardu kodowania.

Utrzymywanie swojego serwera CI nie zawsze się opłaca – zwłaszcza, jeśli zespół jest niewielki. Z pomocą przychodzą wtedy usługi chmurowe. Nie musimy opłacać admina – jak w przypadku swojego serwera, bo wykupujemy (czasem nawet dostajemy za darmo) usługę, która jest dla nas utrzymywana.

Bitbucket Pipelines

Jak to działa?

Tak właśnie jest w jednym z projektów w którym uczestniczę. Repozytorium jest już w chmurze – na bitbucket.org, więc postanowiłem dać szansę ich CI – Bitbucket Pipelines. 50 minut do wykorzystania dostajemy co miesiąc za darmo.

Całe środowisko oparte jest o kontenery Dockera, co daje elastyczność, jeśli chodzi o konfigurację. Całość tejże została sprowadzone do jednego pliku yml trzymanego w głównym katalogu repozytorium – “bitbucket-pipelines.yml”

W moim projekcie używam docker-compose do stawiania środowiska. Chciałem, więc, żeby identyczne środowisko uruchamiało się podczas budowania projektu. Pipelines nie mają z pudełka obsługi docker-compose – można bezpośrednio definiować dodatkowe serwisy takie jak MySQL, ale to by oznaczało utrzymanie zduplikowanej konfiguracji: jednej dla docker-compose, drugiej dla Bitbucket Pipelines. Mało praktyczne.

Docker-compose z Bitbucket Pipelines

Można użyć “docker-in-docker”, czyli obrazu Dockera, który sam w sobie jest Dockerem (musimy dodać tylko docker-compose). Opisał to autor tego artykułu.

Przykładowy plik z konfiguracją może wyglądać tak:

Nawet bez czytania przejrzystej dokumentacji Pipelines – łatwo się domyśleć, że mamy zdefiniowane w powyższym przykładzie 3 pipeline’y w tym jeden odpalany przy pull-requestach.

Niektóre funkcje warte wspomnienia

Warto wspomnieć, że narzędzie potrafi parsować pliki xml w formacie junit i wyświetlać informacje o wynikach naszych testów.

Pipelines umożliwia zrównoleglanie kroków (co zaoszczędza zużywany czas) – niestety przy korzystaniu z docker-compose nie udało mi się przyspieszyć żadnego z moich pipeline’ów.

Żeby nie tracić niepotrzebnie cennych minut autorzy udostępniają nam cache – np. Composera.

Jakieś problemy muszą być

Poza brakiem natywnej obsługi docker-compose, scheduler do uruchamiania pipeline’ów nie rozpoznaje prawidłowo branchy z “/” w nazwie (zgłoszony i jeszcze nie naprawiony błąd z API Bitbucket).

Czy warto zostać hydraulikiem?

W opisywanym przeze mnie przypadku – jak najbardziej warto. Nawet, jeśli te darmowe 50 minut to za mało, abonament zaczyna się od 10$ za 500 minut, a tu już spokojnie wystarczy na mały, a może i średni projekt.