Po niezliczonych dniach i nocach poświęconych ręcznemu tworzeniu aplikacji, w końcu postanowiliśmy usprawnić część naszego procesu za pomocą automatyzacji.
Ale… dlaczego?
Naszym głównym celem wdrożenia systemu Continuous Integration było skrócenie czasu poświęcanego na budowanie aplikacji. W poprzednim projekcie pojedyncze buildy trwały czasami ponad pół godziny, więc postanowiliśmy sobie nieco ułatwić pracę. Oto kluczowe funkcje, które chcieliśmy zrealizować:
- Dostęp do buildów online, gotowych do pobrania
- Obsługa wielu wersji Unity
- Budowanie na iOS, Windows i Android na jednej maszynie z Windows
- Przechowywanie buildów na naszym serwerze lokalnym
(Nasz proces Continuous Integration w kilku prostych krokach)
O GitLab CI
Wybraliśmy GitLab CI, ponieważ nasze repozytoria już tam były hostowane. Szczegóły konfiguracji GitLab i Runnera opisaliśmy w osobnym artykule.
Podczas konfigurowania naszego GitLab Runnera skonfigurowaliśmy pipeline CI za pomocą pliku .gitlab-ci.yml.
Nasz system działa w dwóch etapach: build i deploy. Zadanie „build” służy jako szablon dla wszystkich zadań specyficznych dla platform. Uruchamia ono skrypt PowerShell, który odpala Unity w trybie batch oraz wywołuje nasz własny skrypt build w C#.
Aby to osiągnąć, korzystamy z następujących opcji w linii poleceń Unity:
| C:\’Program Files’\Unity\Editor\Unity.exe | Uruchamia plik wykonywalny Unity |
| -batchmode | Uruchamia Unity bez otwierania edytora |
| -nographics | Zapewnia brak interfejsu GUI na Windows |
| -executeMethod BuildScript.Build | Wywołuje metodę „Build” w naszym BuildScript |
| -projectPath %CI_PROJECT_DIR% | Wskazuje Unity katalog projektu |
| -quit | Zamyka Unity po zakończeniu builda |
Oraz dowolne dodatkowe zmienne, np. -customProjectName %CI_PROJECT_NAME%.
GitLab udostępnia zmienne takie jak nazwa projektu, ID pipeline, katalog projektu czy cel builda. Przekazujemy je do naszego skryptu Unity, aby określić, na jaką platformę zbudować aplikację.
.build: &build
stage: build
variables:
tags:
- Unity
script:
- C:\"Program Files"\Unity\Hub\Editor\%UNITY_VERSION%\Editor\Unity.exe -projectPath %CI_PROJECT_DIR% -logfile D:\Logs\%BUILD_TARGET%.log -customBuildPath %BUILD_PATH% -customProjectName %CI_PROJECT_NAME% -customBuildTarget %BUILD_TARGET% -pipelineId %CI_PIPELINE_ID% -batchmode -nographics -executeMethod BuildScript.Build -quit
artifacts:
name: "%CI_PROJECT_NAME% %BUILD_TARGET% %CI_PIPELINE_ID%"
paths:
- ./Builds/%CI_PROJECT_NAME%/%CI_PIPELINE_ID%/%BUILD_TARGET%
Buildy na żądanie
Oferujemy cztery opcje buildów: Windows, Android, iOS lub All. Wybiera się je w oknie „Run pipeline”. Obecnie GitLab CI nie obsługuje list zmiennych, dlatego wprowadzamy je ręcznie. Jeśli nie zostanie podany cel, pipeline uruchamia build dla wszystkich platform. Dlatego nasze zadanie „build” jest szablonem — każde zadanie specyficzne dla platformy uruchamia się wyłącznie, gdy podana zostanie właściwa zmienna.
Windows:
>>: *build
variables:
BUILD_TARGET: StandaloneWindows64
BUILD_PATH : ./Builds
only:
variables:
- $Target == "Windows"
- $Target == "windows"
- $Target == "All"
- $Target == null
Harmonogram budowania
Oprócz ręcznych wyzwalaczy, harmonogramujemy buildy po każdym commicie do gałęzi master oraz codziennie o 2:00, korzystając z funkcji Schedules w GitLab CI.
Wersję Unity definiujemy też jako zmienną globalną na początku pliku, co ułatwia jej aktualizację na początku projektu.
Gdzie znaleźć nasze buildy?
Początkowo planowaliśmy zapisywać buildy bezpośrednio na naszym serwerze lokalnym, jednak ograniczenia uprawnień zmusiły nas do kopiowania ich z tymczasowego folderu. Aby uniknąć zapełniania dysku, czyścimy folder tymczasowy po każdym deployu. Buildy wciąż są dostępne jako artefakty w GitLab.
Optymalizacja szybkości
Aby przyspieszyć buildy, wdrożyliśmy Unity Cache Server. Dzięki temu Unity pobiera wstępnie przetworzone zasoby z cache zamiast konwertować je za każdym razem, gdy zmieniamy platformę.
Budowanie aplikacji iOS na Windows
Celem było zrealizowanie wszystkich buildów na jednej maszynie z Windows, bez angażowania Maca. Budowanie pliku .ipa wydawało się niemożliwe na Windows, dopóki nie odkryliśmy pluginu Unity, który to umożliwia. Wymagało to przeniesienia certyfikatów z Maca, ale opłaciło się. Plugin obsługuje interfejs wiersza poleceń, co czyni go idealnym do naszego CI.
Spróbuj samodzielnie
Tak oto wygląda nasza historia tworzenia systemu Continuous Integration z wykorzystaniem GitLab CI i Unity. Było to trudniejsze, niż się wydaje, ale wciąż go udoskonalamy. Nasz proces jest teraz prostszy i szybszy — wypróbuj samodzielnie i stwórz własny!
