Dzisiaj będzie raczej krótki wpis, w którym postaram się napisać kilka słów na temat Continous Integration.
Continous Integration == Jenkins ?
W swojej pracy mam przyjemność brać udział w rozmowach rekrutacyjnych. Czasami rozmowa schodzi na temat ciągłej integracji. Zauważyłem, iż część osób utożsamia Continous Integration (CI) z Jenkinsem (lub czasem z innym toolem, którego akurat używają), ale czy to faktycznie to samo?
Ciągła integracja jest procesem…
Czym jest zatem ta ciągła integracja? W moim rozumieniu jest to proces jak najczęstszej integracji naszych zmian w kodzie z kodem, który znajduję się w repozytorium. Integracja obejmuje również kompilacje kodu, zbudowanie projektu oraz uruchomienie testów.
I w tym całym procesie z pomocą przychodzą nam narzędzia takie jak Jenkins czy TeamCity. Narzędzia te możemy skonfigurować, żeby przeprowadzały powyższe operacje automatycznie. Jenkins, czy inny tool, sprawdza regularnie repozytorium, a gdy wykryje zmiany buduje projekt, a następni uruchamia testy naszej aplikacji.
A może coś więcej?
CI jest według mnie podstawą, o którą powinno się zadbać w każdym projekcie. A co o ile chcemy pójść dalej z automatyzacją? Wtedy powinniśmy rozważyć Continous Delivery oraz Continous Deployment.
Czym się różnią te dwa podejścia? Wydaje mi się, iż najprościej będzie to przedstawić dzięki grafiki.
Jak widać oba podejścia są do siebie bardzo podobne. Różnią się adekwatnie ostatnim krokiem w dostarczaniu aplikacji. W Continous Delivery cały proces jest przeprowadzany automatycznie do momentu wybudowania wersji aplikacji, która będzie gotowa do deploya na serwer produkcyjny.
W Continous Deployment ostatni krok również jest zautomatyzowany i wybudowana wersja trafia automatycznie na produkcje.
Darmowe narzędzie
W ramach tego wpisu pozwolę sobie wpleść kilka słów na temat narzędzia do CI, którego użyłem w swojej aplikacji Plag-Detector. Część narzędzi do CI, tak jak np. Jenkins, jest darmowych, ale wymagają one serwera, na którym będą mogły być uruchomione. o ile nie chcemy/nie możemy posiadać swojego serwera do CI to polecam użyć np. serwisu https://travis-ci.org, który jest darmowym narzędziem do CI. Ma on pewne ograniczenie, a mianowicie możemy go użyć tylko i wyłącznie do projektów, które mamy na naszym koncie GitHub (co w przypadku wymagań konkursów nie jest specjalnie problematyczne ;)).
Moje CI znajduje się tutaj: https://travis-ci.org/lukaszantkowiak/plag-detector.
Konfiguracja Travisa.
Aby Travis działał poprawnie musimy go skonfigurować. Robimy to dzięki pliku .travis.yml, który wrzucamy do głównego katalogu naszego projektu. Poniżej przedstawię listing swojej konfiguracji dla projektu napisanego w Javie 8.
language: java jdk: - oraclejdk8Jak widać najprostsza konfiguracja jest banalna i przyjemna
Kilka słów na koniec
W tym wpisie omówiliśmy pokrótce czym są Continous Integration, Continous Delivery i Continous Deployment oraz jakie są różnice między nimi.
Dodatkowo wspomniałem o Travis-CI, który jest darmowym toolem, i z którego zachęcam skorzystać o ile nie mamy możliwości postawienia toola do CI na swoim serwerze.
