Travis CI to narzędzie do Continuous Integration, dostępne w dwóch wersjach płatnej i darmowej dla projektów o otwartym kodzie źródłowym. Swoją przygodę z tym narzędziem zacząłem około półtora roku temu. Wówczas również stawiałem pierwsze kroki z próbami konfiguracji takich narzędzi.

Jeden plik konfiguracyjny

Plik konfiguracyjny dla Travis’a zapisany jest w formacie yml. Za ten format odpowiada YAML, czyli uniwersalny język do prezentowania danych w sposób odpowiednio ustrukturyzowany. Plik konfiguracyjny powinien mieć nazwę .travis.yml.

Na początku jednak musimy ustalić jakiego rodzaju projekt będzie powiązany z Travisem (w tym artykule przedstawię przykład oparty o nodejs) oraz ustalić procedury, których będziemy się trzymać, pracując nad naszym projektem. Zdecydowana większość projektów budowana jest z wykorzystaniem systemu kontroli wersji GIT. W repozytoriach tego typu najczęściej główny branch to master, który jest bezpośrednio powiązany z wersją produkcyjną aplikacji. Natomiast branch dev lub develop, spotkałem się też z wersją workspace, jest tożsamy z wersją deweloperską kodu, który rozwijamy. Jednoznacznie więc widać, że w naszej procedurze powinniśmy uwzględnić przynajmniej dwie wersje: produkcyjną i deweloperską, poprzez powiązanie kodu z poszczególnych branchy z odpowiednim środowiskiem. Często jest też tak, że obie te wersje znajdują się na różnych serwerach. Na szczęście Travis pozwala nam to wszystko uwzględnić w swojej konfiguracji.

Podstawowa konfiguracja

Pole language powinno zawierać informacje o języku w jakim będziemy realizować proces budowania naszej aplikacji. Drugie pole, wskaże nam na wersję node_js, z której chcemy korzystać. Trzecie pole, które wykorzystamy w naszym przykładzie to pole cache. W tym miejscu możemy wskazać, które katalogi powinny być przekazane do cache’a, aby w przyszłości zmniejszyć zasoby konieczne do wykonania całego procesu - w naszym przypadku pobieranie za każdym razem wszystkich pakietów npm’a będzie raczej zbędnym krokiem.

Proces

Travis dzieli cały proces budowania na fazy. W dokumentacji nazywa się to cyklem życia procesu. W cyklu życia występują dwie główne fazy:

• install - w trakcie tej fazy przygotowywane jest całe środowisko, instalowane są wszystkie niezbędne zależności

• script - w trakcie tej fazy uruchamiany jest proces budowania

Oprócz dwóch głównych faz możemy wydzielić fazy dodatkowe, takie jak:

• before_install

• before_script

• after_script

• after_success

• after_failure

To są fazy, które wystąpią zawsze. Oprócz nich możemy wyróżnić jeszcze fazy opcjonalne, np:

• before_cache

• before_deploy

• deploy

• after_deploy.

Całkiem sporo tego, prawda? Zrozumienie tego, jak wygląda proces budowania, pozwala nam włączać się w różne fazy cyklu życia całego procesu i dodawać nowe zadania, kontrolować proces i wykrywać błędy, których prawdopodobnie samodzielnie byśmy nie wychwycili.

Spójrz na poniższy przykład. Wskazałem, że w fazie script mają wykonać się następujące zadania: npm run test oraz npm run build. Wykonają się one w tej kolejności, w której zostały wyszczególnione. W przypadku, gdyby testy nie przeszły, proces zostanie przerwany, a w panelu Travis’a zobaczymy czerwony komunikat o nieudanym procesie. To samo dotyczy każdego zadania, które wskażesz do wykonania.