Dziś trafia do Was trzecia cześć z serii o ciągłej integracji, która omawia jak skonfigurować narzędzie Travis CI do automatyzacji pracy z hostingiem GitHub. Poniżej umieściłem odnośniki do poprzednich części, w których omówiłem między innymi podstawy związane z procesem Continuous Integration.

Kilka słów o Travis CI

Travis CI jest usługą ciągłej integracji używaną do budowania, testowania i wdrażania oprogramowania hostowanego w GitHub. Travis CI jest dostępny za darmo dla rozwijanych projektów open source na GitHub pod adresem travis-ci.org. W przypadku prywatnych repozytoriów istnieje możliwość wykupienia abonamentu na stronie travis-ci.com. Zakładając konto w serwisie Travis wykorzystujemy poświadczenia z GitHub, upoważniamy Travis CI do naszego konta GitHub. W ten sposób uzyskujemy możliwość synchronizacji/integracji projektów GitHub z Travis CI.

Sign in Travis CI

Build flow

Przetestowanie automatyczne naszego kodu  może odbyć się w wyniku pusha, lub wystawienia pull requesta.

  • Branch build flow
    1. Zmiany w kodzie wypychane są do repozytorium na GitHub
    2. GitHub wyzwala Travis CI do wykonania builda
    3. Travis Ci wykonuje builda zgodnie z komendami z pliku .travis.yml
    4. Pliki zostają umieszczone na serwerze jeśli aplikacja zbudowała się i przeszły testy.
    5. Travis Ci wysyła powiadomienie na temat buildu na pocztę lub Slacka
  • Pull request build flow
    1. Powstaje pull request dla projektu na GitHub
    2. GitHub wyzwala Travis CI do wykonania builda dla pull requesta
    3. Travis Ci wykonuje builda zgodnie z komendami z pliku .travis.yml
    4. Travis aktualizuje status pull requesta
    5. Jeśli build zakończył się sukcesem wykonywany jest merge

Konfiguracja Travis

Do testów na GitHub zostało utworzone nowe repozytorium sample_dotnetcore, do którego została wypchnięta znana z poprzednich dwóch  wpisów solucja z dwoma projektami Sample.Api (webapi) i Sample.Test.EndToEnd (xUnit). Po zalogowaniu się na stronę Travis należy z odczytanej listy repozytoriów GitHub zaznaczyć repozytoria, dla których chcemy skonfigurować proces ciągłej integracji.

Flick repository

Travis CI jest konfigurowany poprzez dodanie pliku o nazwie .travis.yml do głównego katalogu repozytorium. Plik YAML definiuje jak nasz projekt ma być budowany i testowany. Wcięcia w pliku YAML muszą zostać zrobione spacją, nigdy przy użyciu tabulatora.

W pliku określamy język csharp, oraz numer wersji .NET Core SDK.  Identyfikator języka csharp określa, że projekty C#, F# i Visual Basic budowane są za pomocą Mono lub .NET Core w systemie Linux lub macOS. Ustawiamy uruchomienie kompilacji na systemie Ubuntu Trusty 14.04. Domyślnie Travis CI użyje najnowszej wersji Mono dla projektów języka csharp. W celu użycia tylko .NET Core należy wyłączyć Mono poprzez ustawienie wersji Mono na none. W pliku konfiguracyjnym w następnym kroku ustawiamy uruchomienie kompilacji projektu tylko dla commitów na gałęzi master. W sekcji before_script wywołujemy komendę do pobrania zależności dla projektów. W sekcji script definiujemy polecenia, jakie mają zostać wykonane do budowy i testowania projektów.

Badge

Travis umożliwia wygenerowanie obrazka z statusem buildu (badge) i dodanie go do naszego repozytorium. W tym celu na stronie Travis należy kliknąć obok nazwy naszego repozytorium ikonę build i wybrać typ markdown.

buildWygenerowany kod należy wkleić do pliku readme.md w naszym repozytorium i wykonać commit. Efekt końcowy z kodami źródłowymi można zobaczyć na repozytorium GitHub.

Podsumowanie

Artykuł przedstawił integracje konta GitHub z Travis CI i zaprezentował jak przy użyciu pliku konfiguracyjnego .travis.yml zautomatyzować proces budowania i testowania aplikacji .NET Core. Travis CI umożliwia integracje projektów nie tylko dla  języka C#, więcej o tym można doczytać w dokumentacji Travis CI. Kolejny wpis już w następnym tygodniu, jeśli chcesz być na bieżąco z wpisami na moim blogu to zapraszam na Twittera.