Ciągła integracja

Budowanie aplikacji wydaje się być prostą czynnością. Po spełnieniu wszystkich założeń i zależności możemy odpalić serwer lub testy i wszystko działa (lub nie). Programista widzi na ekranie widok sukcesu lub błędu -> budowanie zakończone, projekt działa.

Nic bardziej mylnego!

Sukces w budowaniu projektu na jednym komputerze pod jedną konfiguracją to przysłowiowy czubek góry lodowej. Realia pokazują że jest jednak zupełnie inaczej. Projekt trzeba budować często stosując różne konfiguracje, zależności (lub ich odmienne wersje) czy inne systemy operacyjne.

Praktyczny przykład na bazie apki.org

Podczas pracy nad portalem apki.org bardzo szybko napotkaliśmy podstawowy problem budowania projektu. Był on domyślnie stworzony i budowany na maszynach unixowych (a konkretnie na komputerach z systemem operacyjnym MacOS X). Na maszynach tych bezproblemowa jest konfiguracja całego projektu i jego zależności dla ruby w wersji 2.2. Naturalnym porządkiem rzeczy początkowo przyjęliśmy że w takim wypadku wersja 2.2 jest dla nas oficjalna.

Parę dni później okazało się że pojawiają się problemy. Początkowo zakładaliśmy tworzenie platformy z użyciem maszyny wirtualnej Vagrant. Niestety, problemy wydajnościowe tej maszyny oraz drastycznie duże opóźnienia na warstwie sieciowej sprawiły że porzuciliśmy to rozwiązanie i wróciliśmy do korzystania z różnych systemów operacyjnych.

Budowanie na systemach Mac oraz Linux działało bezproblemowo, natomiast już na etapie pobierania i budowania zależności Windows odmówił współpracy. Przyczyna?

Wtyczka nokogiri budowana jest z użyciem native extensions. Obecna wersja tej wtyczki nie obsługuje wersji ruby 2.2 na maszynach windowsowych. Kilka pośrednich rozwiązań (czy raczej obejść) i patchy niestety nie pomogło.

Co w takim razie robimy? Decyzja była prosta, próbujemy w takim razie wersję 2.1. Budowanie zależności powiodło się, super! Działa! Możemy pracować.

I tutaj czeka na nas nieprzyjemna niespodzianka. Wersja ruby 2.2 wprowadziła naprawdę drobną zmianę składniową przy budowaniu hashy. Problem wyjaśniony jest w krótkim przykładzie:

Drobny kawałek kodu sprawił że połowa aplikacji wywalała błędy w bardzo różnych miejscach.

I super - rozwiązaliśmy problem, aplikacja działa na obu wersjach. Tylko pojawia się teraz problem. Jak projektować i testować system tak, żeby nowo powstały kod był zawsze zgodny w obu wersjach? Obejściem problemu jest przyjęcie używamy wersji 2.1, jednak postanowiliśmy użyć innego sposobu.

Zautomatyzujmy budowanie i testy!

Postanowiliśmy skorzystać z bardzo popularnego rozwiązania jakim jest użycie serwera Continous Integration (z ang. Ciągła integracja). Główną ideą takiego serwera jest śledzenie repozytorium i budowanie (oraz testowanie) kodu we wszystkich zdefiniowanych przez nas konfiguracjach i scenariuszach. Dzięki temu programista wrzucający kod zostaje poinformowany przez serwer CI jeżeli wrzucił do kodu linię zrywającą kompatybilność z innymi konfiguracjami od swojej.

Czas na konkrety

Okej, wiemy już co chcemy zrobić i czemu - pora na realizację.

Wybór serwera był dosć prosty - Travis CI oferuje bardzo prostą konfigurację (z użyciem pojedynczego pliku .travis.yml oraz w pełni darmową usługę dla projektów Open Source. Nasza Konfiguracja wygląda tak:

Ustawiamy:

  • Język projektu jako ruby
  • Cachowanie zależności bundlera (żeby podczas buildu nie było potrzeby pobierania i budowania wszystkich wtyczek)
  • 2 środowiska rvm, wersję 2.2.2 oraz 2.1.6
  • MongoDB jako bazę projektu
  • CodeClimate (do śledzenia jakości naszego kodu)

Dzięki takiej konfiguracji po każdym pushu na serwer Travis CI buduje i testuje nasz projekt równolegle na 2 maszynach wirtualnych (w jednej na wersji ruby 2.1 a w drugiej na 2.2). Jeżeli budowanie lub testy się nie powiodą natychmiast dostaję powiadomienie mailowe o takiej sytuacji i mogę przejrzeć logi w celu znalezienia błędu. Proste, a jakże skuteczne.

Budowanie projektu apki.org można śledzić pod linkiem https://travis-ci.org/media3-0/apki.org

Nekromancer

Programista z zawodu i zamiłowania. W fundacji zajmuje się głównie rozwiązaniami backendowymi oraz aplikacjami mobilnymi. Współtwórca portalu apki.org oraz mentor na forum

Jastrzębie-Zdrój http://ownvision.pl/