Napisanie skryptów budujących to jedno. Konfiguracja serwera CI to drugie. Natomiast połącznie tych dwóch elementów daje więcej niż ich suma. Przedstawiam dzisiaj, na przykładzie, jak uruchomić skrypty CakeBuild na Appveyor z użyciem appveyor.yml. Ten post w dużej części zawiera listing YAMLa wraz z opisem oraz krótki wstęp o konfiguracji tego narzędzia. Zapraszam.

Zakładanie konta i podpięcie repo

Wystartowanie z AppVeyor jest banalnie proste. Proces logowania i rejestracji odbywa się ekspresowo. Zrobiłem to przy użyciu konta GitHub. Po zalogowaniu się, kliknąłem w przycisk `+NEW PROJECT`, a następnie obok nazwy repozytorium mały guzik `+ADD`, wołający cichutko „kliknij mnie”. Po krótkiej chwili oczekiwania narzędzie było gotowe i chętne, aby je skonfigurować.

Sposoby Konfiguracji

AppVeyor może być skonfigurowany na dwa sposoby.

• GUI – czyli poprzez interfejs użytkownika. Taka opcja jest dobra na start, pod warunkiem, że są Twoje pierwsze kroki z konfiguracją CI. W takiej sytuacji polecam metodę prób i błędów, aby sprawdzić jak to działa. Dodatkowym atutem AppVeyor jest możliwość wygenerowania pliku YAML z wyklikanej konfiguracji. Dzięki temu, nawet czas spędzony na klikaniu nie będzie czasem straconym.
• YAML – druga, według mnie lepsza opcja. Dlaczego? Ponieważ z tym podejściem konfiguracja serwera CI może być wersjonowana w repozytorium i rozwijana wraz z kodem. Dzięki czemu możliwe są publikacje starszych wersji aplikacji.

Konfiguracja

Przedstawiona niżej konfiguracja składa się z części: definicja zmiennych środowiskowych, ustawienie parametrów agenta oraz uruchomienie skryptów, najpierw budujących, potem publikujących.

Zmienne środowiskowe

Deplojment wymaga loginów, haseł i adresów. Muszą one zostać przekazane do skryptów, ale gdzieś trzeba je wcześniej zdefiniować. Oczywistym wyborem jest plik YAML. Musisz jednak mieć na uwadze, że zostanie on wbity do repozytorium. W związku z tym, parametry, w szczególności wrażliwe, powinny zostać zaszyfrowane. Na szczęście AppVeyor to umożliwia. W opcjach jest podstrona `Encrypt data` pozwalająca na zaszyfrowanie zmiennych środowiskowych.

environment:
  deploy_apiSiteName: 
    secure: q0b3qJ1VOdhElr8AxVxaIw==
  deploy_apiSitePassword: 
    secure: YhFw+Tk8hTX2rI+iTrxP1qNrCvPU9lvHw07bRYjY/T1Z14cPtcHWp6DmiyLcWrUYFy/zi8RIdjmiC/+KsQKZng==
  deploy_webSiteName: 
    secure: UBxXc3ZqMJU5SQoNtHBmwA==
  deploy_webSitePassword: 
    secure: XT4QneWux4gDAHxxSh0XwrBXDDLR25m1bQLfkkbYCQ+tXX3oz8GhiCLy0YxY+mYKHT8SiAzzqeFLhVf8E4Ircg==
  deploy_dbServer: 
    secure: KCni3IknxZAYDRpPixWPIQ==
  deploy_dbInitialCatalog: 
    secure: QT93jA5/gGLb8GVur176Pg==
  deploy_dbUserID: 
    secure: w/CziMaQ9ZSnU94JGKbrjChi86jvgzDwzEA7+VQS0tk=
  deploy_dbPassword: 
    secure: T+Mj1pN4SIZg+BkAi61balv9wppriBYugeyu/vat5kw=

Ustawienia agenta

Każdy projekt może wymagać innej konfiguracji agenta. W związku z tym ustawiam odpowiednie właściwości dla mojego projektu. Oto one:

• `version` – definicja numeru builda. Wyświetla się on w interfejsie użytkownika, ale również można go przekazać do aplikacji, aby było wiadomo która wersja jest aktualnie na produkcji.
• `image` – określenie jakiego obrazu chcę użyć podczas odpalania skryptów. Od tego zależy jaka wersja Visual Studio, PowerShella czy innego narzędzia będzie dostępna. Szczegółowa lista znajduje się tu[https://www.appveyor.com/docs/build-environment/].
• `services` – włączenie dodatkowego ficzera. Domyślnie różne usługi są wyłączone ponieważ ich uruchomienie zajmuje czas i zasoby. W tym przypadku potrzebuję SqlServera, ponieważ odpalam testy na bazie danych.
• `shallow_clone` – opcja, aby kod był pobierany jako paczka ZIP, a nie klonowany. Jest to opcja szybsza. Zwłaszcza, przy dużych repozytoriach. Warto mieć na uwadze, że działa z GitHubem, ale może nie działać z innymi serwisami.
• `test` – wyłączenie testów. Robię to świadomie, ponieważ uruchamiam testy w skrypcie budującym.
• `cache` – zabieg optymalizacyjny. Jeżeli jakieś pliki musza być pobierane z internetu za każdym razem to warto uzyć kesza. Dzięki temu bardzo skrócisz czas builda. Zwłaszcza, jeżeli uruchamiasz `npm install`.

version: 1.0.{build}
image: Visual Studio 2017
services:
  - mssql2017
shallow_clone: true
test: off
cache:
  - src/IsTableBusy/packages
  - '%LocalAppData%\NuGet\v3-cache'

Build

Czas na przygotowanie paczki. Wreszcie konkrety. W krokach `buids_scripts` i `after_build` uruchamiam skrypty PowerShellowe. W pierwszym przekazuję ścieżkę do pliku 'build.cake'. Muszę to zrobić, ponieważ domyślnie jestem w głównym katalogu, a PowerShell jako bieżącą lokalizację taktuje miejsca wywołania, a nie lokalizację skryptu. Następnie tworzę plik określający wersję, abym wiedział co to za paczka, jeżeli miałbym potrzebę publikowania paczki z innego narzędzia. Na koniec definiuję z jakiej ścieżki powinien zostać stworzony artefakt.

build_script:
  - ps: ./Deployment/build.ps1 -Script "./Deployment/build.cake"
after_build:
  - ps: echo $env:APPVEYOR_BUILD_VERSION > "./Deployment/packages/buildVersion.txt"
artifacts:
  - path: Deployment/packages

Deploy

Na sam koniec pozostaje już tylko wdrożenie nowej wersji aplikacji. W kroku `deploy_script` uruchamiam skrypt z paczki, z odpowiednimi parametrami. Dodatkowo sprawdzam, czy aktualny kod jest z mastera i czy jest to pull request. Jeżeli oba warunki są spełnione kontynuuję.

deploy_script:
  ps: | 
    if($env:APPVEYOR_REPO_BRANCH -ne 'master' -or $env:APPVEYOR_PULL_REQUEST_NUMBER -ne $null)
    {
      Write-Host 'Do not deploy for branches diffrent than master or for pull requests'
      return
    }
  ./Deployment/packages/deploy.ps1 `
  -Script "./Deployment/packages/deploy.cake" `
  -ScriptArgs ("-apiSiteName=""$env:deploy_apiSiteName""", `
  "-apiSitePassword=""$env:deploy_apiSitePassword""", `
  "-webSiteName=""$env:deploy_webSiteName""", `
  "-webSitePassword=""$env:deploy_webSitePassword""", `
  "-dbServer=""$env:deploy_dbServer""", `
  "-dbInitialCatalog=""$env:deploy_dbInitialCatalog""", `
  "-dbUserID=""$env:deploy_dbUserID""", `
  "-dbPassword=""$env:deploy_dbPassword""")

U mnie działa! A u Ciebie?

I to wszystko na dzisiaj. Jak Twoje wrażenia odnośnie konfiguracji przy użyciu plku YAML? Czy już to kiedyś robiłeś? Czy masz jakieś wskazówki? Jakie Ty masz podejście do konfiguracji serwera ciągłej integracji? Zapraszam do komentowania.