CI oraz CD

CI czyli Continuous Integration oraz CD czyli Continuous Deployment to dwa podejścia bez których jeszcze kilka lat temu mogłem spokojnie żyć. Wówczas nie doceniałem automatyzacji takich procesów jak publikacja aplikacji na serwerze czy uruchomienie testów przed publikacją. Doświadczenie jednak uczy.

CI to nic innego jak praktyka polegająca na sprawdzaniu zmian, które zachodzą w naszym kodzie za każdym razem, gdy pojawią się one w repozytorium. Weryfikacja polega najczęściej na testowym zbudowaniu aplikacji, uruchomieniu testów jednostkowych oraz testów end-2-end, a także zweryfikowanie jakości dostarczonych zmian: poprzez sprawdzenie powtórzeń w kodzie, określenie poziomu długu technologicznego, stopnia pokrycia testami itp.

Praktyki CI stosujemy po to, aby zmniejszyć ryzyko wystąpienia krytycznych błędów, szybciej wykrywać błędy oraz zminimalizować koszty łączenia pracy różnych osób. Brzmi dobrze, prawda?

Natomiast CD odpowiada za umieszczenie naszej już zbudowanej aplikacji na serwerze. Kiedyś ręcznie logowałem się na serwer poprzez FTP i przenosiłem pliki do odpowiednich katalogów. Wymagało to ode mnie dużo cierpliwości, skupienia, czasu i odporności na ewentualne błędy podczas kopiowania plików. Na szczęście wprowadzenie CD do mojej pracy pozwoliło mi skończyć z tym procederem.

Dostępne narzędzia

Na rynku mamy bardzo dużo różnych narzędzi, które pozwalają nam budować i zarządzać procesami CI oraz CD. Do najpopularniejszych na pewno zaliczyć można:

• CircleCI

• Buddy

• Jenkins

• GitLab

• Bamboo

• Travis CI

Wow. Troszkę tego jest - co wybrać?

Właściwie to jest bardzo trudne pytanie, ponieważ każde z powyższych narzędzi może spisywać się bardzo dobrze. Konfiguracja każdego może być przeprowadzona za pomocą dodania odpowiednich plików konfiguracyjnych dodanych do naszego repozytorium lub “wyklikana” w panelu danego narzędzia. Wybór zależy od osobistych preferencji - korzystając z Bitbucket’a prawdopodobnie nasz wzrok skierujemy w kierunku Bamboo, lubując się w technologiach Open Source prawdopodobnie wybierzemy Jenkinsa lub Travisa, natomiast jeśli doceniamy proste i intuicyjne interfejsy - to Buddy będzie ciekawym wyborem. Nie chciałbym wyrokować, które narzędzie jest najlepsze. Korzystałem jak dotąd z kilku - w prywatnych projektach pracuję natomiast z Travisem.

Pipelines

Mówiąc o CI warto wspomnieć o pipeline’ach. Najprościej mówiąc: pipeline to ścieżka, procedura, która musi zostać wykonana w trakcie CI. Taka ścieżka może zawierać następujące kroki:

• nasłuchiwanie na zmianę w repozytorium (commit, PR)

• uruchomienie procesu budowania aplikacji

• instalacja potrzebnego oprogramowania / konfiguracja środowiska

• proces budowania aplikacji

• uruchomienie testów jednostkowych

• uruchomienie testów e2e

• powiadomienie o wynikach testów oraz procesu budowania (np. poprzez mail, Slack itp)

• deploy

W przypadku dobrze przygotowanej procedury każdy błąd zostanie zgłoszony i uchroni nas przed opublikowaniem kodu, który nie będzie spełniał minimalnych wymagań, jeśli chodzi o dostarczaną jakość.

CI a różne środowiska

Czasami zdarzają się sytuacje, gdy mamy kilka różnych branchy, z których kod powinien wylądować na różnych serwerach. Np. master - jako branch produkcyjny na serwer produkcyjny, develop - na serwer deweloperski, staging - na serwer testowy. W ramach całego procesu CI możemy takie różnice określić i wskazać, który kod gdzie ma trafić. W kolejnych wpisach postaram się pokazać Wam jak taką procedurę określić w narzędziu Travis CI.

CD - Continuous Deployment czy Continuous Delivery?

Pod skrótem CD można też znaleść hasło Continuous Delivery. Czym się różni od Continuous Deployment? W Continuous Delivery pojawia się również strona biznesowa, która w odpowiednim momencie musi fizycznie zatwierdzić opublikowanie zmian na serwerze. Takie zabezpieczenie może mieć sens, kiedy /biznes/ chce mieć wpływ na czas dostarczania nowych funkcjonalności.

Podsumowanie

Praca dewelopera wymaga bardzo często skupienia, cierpliwości i dużej uwagi. Czasami popełniamy “głupie” błędy, które trudno wychwycić. CI oraz CD mają nam pomóc wyeliminować publikację takich błędów oraz je wcześniej wykrywać - chociażby z tego powodu warto zaznajomić się z takimi procesami.

Dzięki CI oraz CD hasło: /deploy w piątek/ nie musi brzmieć tak strasznie jak kiedyś. Dobrze napisana procedura czasami może nam zagwarantować spokojny weekend.

I tego Wam życzę. ;)