GitHub Actions vs GitLab CI dla backendu, aplikacji web i mobilnych

Z czym ludzie mają problemy w CI dla wielu aplikacji

Gdy jedno repo buduje backend, aplikację web i aplikacje mobilne, CI przestaje być „po prostu uruchom testy”. Staje się kontrolerem ruchu dla różnych toolchainów, różnych czasów buildów i różnych reguł wydawania.

Najczęstszy ból jest prosty: jedna mała zmiana uruchamia zbyt dużo pracy. Edycja dokumentacji uruchamia podpisywanie iOS, albo poprawka backendu wymusza pełny rebuild weba — i nagle każdy merge wydaje się powolny i ryzykowny.

W konfiguracjach z wieloma aplikacjami pojawia się kilka wczesnych problemów:

• Runner drift: wersje SDK różnią się między maszynami, więc buildy zachowują się inaczej w CI i lokalnie.
• Rozsypane sekrety: klucze API, certyfikaty do podpisywania i dane sklepów powielają się między zadaniami i środowiskami.
• Zamieszanie z cache'em: zły klucz cache tworzy przestarzałe buildy, a brak cache sprawia, że wszystko jest boleśnie wolne.
• Mieszane reguły wydawania: backendy chcą częstych deployów, a wydania mobilne są przepustkowane i wymagają dodatkowych kontroli.
• Czytelność pipeline’a: konfiguracja rozrasta się do ściany zadań, której nikt nie chce dotykać.

Dlatego wybór między GitHub Actions a GitLab CI ma większe znaczenie w monorepo niż w projektach jednoaplikacyjnych. Potrzebujesz jasnych sposobów na podział pracy według ścieżek, bezpieczne dzielenie artefaktów i zapobieganie kolizjom równoległych zadań.

Praktyczne porównanie sprowadza się do czterech rzeczy: konfiguracja i skalowanie runnerów, przechowywanie i zakres sekretów, cache i artefakty oraz jak łatwo wyrazić „buduj tylko to, co się zmieniło” bez zmieniania pipeline w kruchej zupie reguł.

Chodzi o codzienną niezawodność i utrzymanie, nie o to, która platforma ma więcej integracji czy ładniejszy interfejs. To też nie zastępuje decyzji o narzędziach buildowych (Gradle, Xcode, Docker itp.). Ma pomóc wybrać CI, które ułatwia utrzymanie czystej struktury.

Jak zbudowane są GitHub Actions i GitLab CI

Największa różnica to organizacja pipeline’ów i ponowne użycie, co zaczyna mieć znaczenie, gdy backend, web i mobile współdzielą repo.

GitHub Actions przechowuje automatyzacje w plikach YAML pod .github/workflows/. Workflowy uruchamiają się na zdarzenia jak push, pull request, harmonogram czy uruchomienia ręczne. GitLab CI skupia się wokół .gitlab-ci.yml w katalogu root, z opcjonalnymi plikami do includowania; pipeline’y zwykle uruchamiają się na push, merge request, harmonogramy i zadania ręczne.

GitLab opiera się na stages. Definiujesz etapy (build, test, deploy), a potem przypisujesz zadania do etapów, które wykonują się w kolejności. GitHub Actions opiera się na workflowach zawierających joby. Joby domyślnie działają równolegle — dodajesz zależności, gdy jeden musi poczekać na drugi.

Do uruchamiania tej samej logiki na wielu targetach, matrix GitHub jest naturalnym wyborem (iOS vs Android, różne wersje Node). GitLab potrafi osiągnąć podobny efekt przez parallel jobs i zmienne, ale często trzeba samodzielnie połączyć więcej elementów.

Reuse też wygląda inaczej. W GitHub zespoły zwykle korzystają z reusable workflows i composite actions. W GitLab reuse często osiąga się przez include, współdzielone szablony i anchor/extends w YAML.

Różnią się też zatwierdzenia i chronione środowiska. GitHub często używa protected environments z wymaganymi recenzentami i sekretami środowiska, więc deploy do produkcji zatrzyma się do momentu akceptacji. GitLab łączy chronione branche/tagi, chronione środowiska i zadania manualne, by tylko określone role mogły uruchamiać deploy.

Konfiguracja runnera i wykonanie zadań

To tu obie platformy zaczynają różnić się w codziennym użyciu. Obie pozwalają na hostowane runnery (nie zarządzasz maszyną) lub self‑hosted (ty jesteś właścicielem maszyny, aktualizacji i bezpieczeństwa). Hostowane runner’y są prostsze na start; self‑hosted często są potrzebne dla szybkości, specjalnych narzędzi lub dostępu do sieci wewnętrznej.

Praktyczny podział w wielu zespołach to Linux dla backendu i weba, a macOS tylko gdy trzeba zbudować iOS. Android można uruchamiać na Linuxie, ale jest ciężki, więc rozmiar runnera i miejsce na dysku mają znaczenie.

Hostowane vs self‑hosted: co musisz zarządzać

Hostowane runnery pasują, gdy chcesz przewidywalnej konfiguracji bez utrzymania. Self‑hosted sens ma, gdy potrzebujesz specyficznych wersji Java/Xcode, szybszych cache’y lub dostępu do sieci wewnętrznej.

Jeśli wybierasz self‑hosted, zdefiniuj role runnerów wcześnie. Większość repo radzi sobie dobrze z niewielkim zestawem: ogólny Linux dla backend/web, mocniejszy Linux dla Androida, macOS dla pakowania i podpisywania iOS oraz osobny runner do deployów z ostrzejszymi uprawnieniami.

Wybór odpowiedniego runnera do zadania

Obie platformy pozwalają celować w określone runnery (labels w GitHub, tags w GitLab). Nazewnictwo trzymaj powiązane z obciążeniem, np. linux-docker, android, macos-xcode15.

Izolacja to źródło wielu flaków. Pozostałe pliki, współdzielone cache’e, które się korumpują, albo narzędzia instalowane „ręcznie” na self‑hosted maszynie mogą generować losowe błędy. Czyste workspace’y, przypisane wersje narzędzi i zaplanowane czyszczenie runnerów szybko się zwracają.

Pojemność i uprawnienia to kolejne powtarzające się bolączki, zwłaszcza dostępność macOS i jej koszty. Dobry domyślny podział: buildy mogą budować, deployy mogą wdrażać, a produkcyjne dane uwierzytelniające żyją w jak najmniejszym zestawie zadań.

Sekrety i zmienne środowiskowe

Sekrety to miejsce, gdzie pipeline’y multi‑app stają się ryzykowne. Fundamenty są podobne (przechowuj sekrety na platformie, wstrzykuj w czasie runu), ale zakresowanie różni się.

GitHub Actions zwykle zakresuje sekrety na poziomie repo i organizacji, z dodatkową warstwą Environments. Ta warstwa jest przydatna, gdy produkcja potrzebuje bramek manualnych i oddzielnych wartości od stagingu.

GitLab CI używa zmiennych CI/CD na poziomie projektu, grupy lub instancji. Obsługuje też zmienne zakresowane na środowiska oraz protekcje jak „protected” (dostępne tylko na chronionych branchach/tagach) i „masked” (ukryte w logach). Te mechanizmy są pomocne, gdy jedno monorepo obsługuje wiele zespołów.

Główny błąd to przypadkowe ujawnienie: debug, nieudane polecenie, które echo’uje zmienne, albo artefakt zawierający plik konfiguracyjny. Traktuj logi i artefakty jako potencjalnie współdzielone domyślnie.

W pipeline dla backendu + web + mobile sekrety to zwykle poświadczenia chmury, URL‑e baz danych i klucze API, materiały do podpisywania (certyfikaty/prospy iOS, keystore i hasła Android), tokeny rejestracyjne (npm, Maven, CocoaPods) oraz tokeny automatyzacji (powiadomienia, boty).

Dla wielu środowisk (dev, staging, prod) trzymaj nazwy spójne i zamieniaj wartości przez zakres środowiska zamiast kopiować zadania. Dzięki temu rotacja i kontrola dostępu są prostsze.

Kilka zasad zapobiegających większości incydentów:

• Preferuj krótkotrwałe poświadczenia (np. OIDC do dostawców chmury) zamiast długowiecznych kluczy.
• Stosuj zasadę najmniejszych uprawnień: oddziel tożsamości deployowe dla backendu, weba i mobile.
• Maskuj sekrety i unikaj wypisywania zmiennych środowiskowych, nawet w błędach.
• Ogranicz produkcyjne sekrety do chronionych branchy/tagów i wymaganych recenzentów.
• Nigdy nie przechowuj sekretów w artefaktach, nawet tymczasowo.

Prosty, wysokowyciągowy przykład: zadania mobilne powinny otrzymywać sekrety do podpisywania tylko przy tagowanych wydaniach, a zadania deployu backendu mogą używać ograniczonego tokena przy merge’ach do main. Sama ta zmiana zmniejsza zakres szkód przy błędnej konfiguracji zadania.

Cache i artefakty dla szybszych buildów

Większość wolnych pipeline’ów jest powolna z nudnego powodu: wielokrotnie ściągają i przebudowują te same rzeczy. Cache zapobiega powtarzanej pracy. Artefakty rozwiązują inny problem: zachowanie dokładnych wyników z konkretnego runu.

Co cache’ować zależy od tego, co budujesz. Backendom pomagają cache’e zależności i kompilatora (np. cache Go modules). Web zyskuje na cache’u menedżera pakietów i narzędzi buildowych. Mobile często potrzebuje Gradle i cache’a Android SDK na Linuxie oraz CocoaPods lub Swift Package Manager na macOS. Uważaj na agresywne cache’owanie iOS build output (np. DerivedData), jeśli nie rozumiesz kompromisów.

Obie platformy stosują ten sam wzorzec: przywróć cache na początku zadania, zapisz zaktualizowany cache na końcu. Różnica w codziennej pracy to kontrola. GitLab robi cache i artefakty explicite w jednym pliku, łącznie z wygaśnięciem. GitHub Actions częściej polega na oddzielnych actions do cache’u — to elastyczne, ale łatwiej to źle skonfigurować.

Klucze cache mają większe znaczenie w monorepo. Dobre klucze zmieniają się, gdy zmieniają się wejścia, i są stabilne w przeciwnym razie. Lockfile’y (go.sum, pnpm-lock.yaml, yarn.lock i podobne) powinny napędzać klucz. Pomaga też hash konkretnego folderu aplikacji, a nie całego repo, i trzymanie oddzielnych cache’y per aplikacja, żeby jedna zmiana nie unieważniała wszystkiego.

Używaj artefaktów do przechowywania rezultatów, które chcesz zachować z danego runu: paczki wydawnicze, APK/IPA, raporty testowe, coverage i metadane builda. Cache to przyspieszenie; artefakt to zapis.

Jeśli buildy nadal są wolne, szukaj zbyt dużych cache’y, kluczy, które zmieniają się przy każdym runie (timestampy, SHA commitów) oraz cache’owanych wyników, które nie są współdzielne między runnerami.

Dopasowanie do monorepo: wiele pipeline’ów bez chaosu

Monorepo robi się nieczytelne, gdy każdy push uruchamia testy backendu, build weba i podpisy mobilne, nawet jeśli zmieniłeś tylko README. Czysty wzorzec to: wykryj, co się zmieniło, i uruchom tylko potrzebne zadania.

W GitHub Actions często oznacza to osobne workflowy na aplikację z filtrami opartymi na ścieżkach, żeby każdy workflow uruchamiał się tylko przy zmianach w swoim obszarze. W GitLab CI zwykle robi się to jednym plikiem pipeline z rules:changes (lub child pipelines), żeby tworzyć lub pomijać grupy zadań na podstawie ścieżek.

Wspólne pakiety to miejsce, gdzie zaufanie pęka. Jeśli packages/auth się zmienia, backend i web mogą wymagać przebudowy nawet jeśli ich foldery nie zmieniły się. Traktuj współdzielone ścieżki jako wyzwalacze dla wielu pipeline’ów i trzymaj granice zależności przejrzyste.

Prosty mapownik wyzwalaczy, który ogranicza niespodzianki:

• Zadania backendowe uruchamiają się przy zmianach w backend/** lub packages/**.
• Zadania webowe uruchamiają się przy zmianach w web/** lub packages/**.
• Zadania mobilne uruchamiają się przy zmianach w mobile/** lub packages/**.
• Zmiany tylko w dokumentacji uruchamiają szybkie sprawdzenie (formatowanie, spellcheck).

Paralelizuj to, co bezpieczne (testy jednostkowe, lint, build web). Szereguj to, co wymaga kontroli (deployy, wydania do sklepów). Zarówno needs w GitLab, jak i zależności jobów w GitHub pomagają uruchamiać szybkie checks na początku i zatrzymywać resztę, gdy coś padnie.

Trzymaj podpisywanie mobilne odsunięte od codziennego CI. Umieść klucze podpisywania w dedykowanym środowisku z ręczną aprobatą i uruchamiaj podpisy tylko przy tagowanych wydaniach lub na chronionych branchach. Pull requesty nadal mogą budować niezapisywane aplikacje do weryfikacji bez ujawniania wrażliwych poświadczeń.

Krok po kroku: czytelny pipeline dla backendu, weba i mobile

Czysty multi‑app pipeline zaczyna się od nazewnictwa, które jasno pokazuje intencję. Wybierz jeden wzorzec i się go trzymaj, żeby ludzie mogli szybko przejrzeć logi i wiedzieć, co zostało uruchomione.

Jeden schemat, który zostaje czytelny:

• Pipeline’y: pr-checks, main-build, release
• Środowiska: dev, staging, prod
• Artefakty: backend-api, web-bundle, mobile-debug, mobile-release

Stąd trzymaj zadania małe i promuj tylko to, co przeszło wcześniejsze kontrole:

1. PR checks (każdy pull request): uruchom szybkie testy i lint tylko dla aplikacji, które się zmieniły. Dla backendu zbuduj artefakt możliwy do deployu (container image lub bundle serwera) i zapisz go, żeby późniejsze kroki nie przebudowywały tego samego.

2. Web build (PR + main): zbuduj aplikację web do postaci statycznego bundle. W PR zostaw output jako artefakt (albo wdroż podgląd, jeśli masz środowisko preview). Na main wygeneruj wersjonowany bundle dla dev lub staging.

3. Mobile debug builds (PR tylko): zbuduj debugowe APK/IPA. Nie podpisuj do release. Cel to szybka informacja zwrotna i plik, który testerzy mogą zainstalować.

4. Release builds (tylko tagi): przy tagu jak v1.4.0 uruchom pełne buildy backendu i weba oraz podpisane buildy mobilne do wydania. Wygeneruj outputy gotowe do sklepów i zachowaj notatki wydania razem z artefaktami.

5. Ręczne zatwierdzenia: umieść zatwierdzenia między staging a prod, nie przed podstawowymi testami. Deweloperzy mogą uruchamiać buildy, ale tylko uprawnione role powinny wdrażać do produkcji i mieć dostęp do sekretów produkcyjnych.

Częste błędy, które marnują czas

Zespoły często tracą tygodnie przez nawyki robocze, które cicho tworzą flaki w buildach.

Jedną pułapką jest poleganie za bardzo na współdzielonych runnerach. Gdy wiele projektów konkuruje o ten sam pul, dostajesz losowe time‑outy, wolne zadania i buildy mobilne, które padają tylko w godzinach szczytu. Jeśli backend, web i mobile są ważne, izoluj ciężkie zadania na dedykowanych runnerach (albo przynajmniej oddzielne kolejki) i trzymaj limity zasobów jawne.

Sekrety to kolejny pożeracz czasu. Klucze i certy do podpisywania mobilnego łatwo źle obsłużyć. Częsty błąd to przechowywanie ich zbyt szeroko (dostępne w każdym branchu i zadaniu) lub wycieki przez verbose logi. Trzymaj materiały do podpisywania ograniczone do chronionych branchy/tagów i unikaj kroków, które wypisują wartości sekretów (nawet base64).

Cache może zawieść, gdy zespoły cache’ują ogromne katalogi lub mylą cache z artefaktami. Cache’uj tylko stabilne wejścia. Wyniki, których potrzebujesz później, trzymaj jako artefakty.

Na koniec: w monorepo uruchamianie wszystkiego przy każdej zmianie pali minuty i cierpliwość. Jeśli ktoś poprawi README i przebudujesz iOS, Android, backend i web — ludzie przestaną ufać CI.

Szybka lista kontrolna, która pomaga:

• Używaj reguł opartych na ścieżkach, żeby uruchamiać tylko dotknięte aplikacje.
• Oddziel zadania testowe od deployowych.
• Trzymaj klucze podpisywania ograniczone do workflowów wydawniczych.
• Cache’uj małe, stabilne wejścia, nie całe foldery buildów.
• Zaplanuj przewidywalną pojemność runnerów dla ciężkich buildów mobilnych.

Szybkie sprawdzenia przed podjęciem decyzji o platformie

Zanim wybierzesz, zrób kilka testów odzwierciedlających wasz sposób pracy. Uchroni cię to przed wyborem narzędzia, które działa ok dla jednej aplikacji, ale staje się męką po dodaniu mobilnych buildów, wielu środowisk i workflowów wydawniczych.

Skoncentruj się na:

• Planie runnerów: hostowane, self‑hosted czy mix. Buildy mobilne często kierują zespoły w stronę miksu, bo iOS wymaga macOS.
• Planie sekretów: gdzie sekrety żyją, kto może je czytać i jak działa rotacja. Produkcja powinna być bardziej zamknięta niż staging.
• Planie cache’u: co cache’ujesz, gdzie jest przechowywane i jak są formowane klucze. Jeśli klucz zmienia się w każdym commicie, zapłacisz bez przyspieszenia.
• Planie monorepo: filtry ścieżek i czysty sposób na współdzielenie kroków (lint, testy) bez copy‑paste.
• Planie wydania: tagi, zatwierdzenia i separacja środowisk. Bądź konkretny, kto może promować do produkcji i jakie dowody są potrzebne.

Przetestuj te odpowiedzi na małym scenariuszu. W monorepo z Go backendem, aplikacją Vue i dwiema aplikacjami mobilnymi: zmiana w dokumentacji powinna robić prawie nic; zmiana backendu powinna uruchomić testy backendu i zbudować artefakt API; zmiana UI mobilnego powinna zbudować tylko Android i iOS.

Jeśli nie potrafisz opisać tego flow na jednej stronie (wyzwalacze, cache, sekrety, zatwierdzenia), zrób tygodniowy pilotaż na obu platformach z tym samym repo. Wybierz tę, która wydaje się nudna i przewidywalna.

Przykład: realistyczny flow buildów i wydań w monorepo

Wyobraź sobie jedno repo z trzema folderami: backend/ (Go), web/ (Vue) i mobile/ (iOS i Android).

Na co dzień chcesz szybkiego feedbacku. Przy wydaniach chcesz pełnych buildów, podpisywania i kroków publikacji.

Praktyczny podział:

• Branchy feature’owe: uruchamiaj lint + unit tests dla zmienionych części, buduj backend i web oraz opcjonalnie debugowy build Androida. Pomijaj iOS, chyba że naprawdę go potrzebujesz.
• Tagi wydaniowe: uruchamiaj wszystko, twórz wersjonowane artefakty, podpisuj aplikacje mobilne i wypychaj binaria do magazynu wydań.

Wybór runnera zmienia się, gdy pojawia się mobile. Go i Vue dobrze działają na Linuxie praktycznie wszędzie. iOS wymaga macOS runnerów, co może przesądzić sprawę. Jeśli zespół chce pełnej kontroli nad maszynami buildowymi, GitLab CI z self‑hosted runnerami może być łatwiejszy do utrzymania jako flota. Jeśli wolisz mniejszy nakład ops i szybkie uruchomienie, hostowane runner’y GitHub są wygodne, ale minuty macOS i ich dostępność trzeba uwzględnić w planie.

Cache to miejsce, gdzie oszczędza się najwięcej czasu, ale najlepszy cache różni się między aplikacjami. Dla Go cache’uj moduły i build cache. Dla Vue cache’uj magazyn pakietów i przebudowuj tylko przy zmianie lockfile’a. Dla mobile cache’uj Gradle i Android SDK na Linuxie; cache’uj CocoaPods lub SPM na macOS i spodziewaj się większych cache’y i częstszego unieważniania.

Zasadniczna reguła: jeśli kod jest już hostowany na jednej platformie, zacznij tam. Przeprowadzaj migrację tylko wtedy, gdy runnery (szczególnie macOS), uprawnienia lub zgodność cię do tego zmuszą.

Kolejne kroki: wybierz, ustandaryzuj i automatyzuj bezpiecznie

Wybierz narzędzie, które pasuje do miejsca, gdzie już jest kod i ludzie. Różnice najczęściej wychodzą w codziennym tarciu: review, uprawnienia i jak szybko ktoś zdiagnozuje złamany build.

Zacznij prosto: jeden pipeline na aplikację (backend, web, mobile). Gdy stanie się stabilne, wyciągnij współdzielone kroki do szablonów, żeby ograniczyć copy‑paste bez zacierania odpowiedzialności.

Zapisz zakresy sekretów tak, jak zapisałbyś, kto ma klucze do biura. Sekrety produkcyjne nie powinny być czytelne przez każdy branch. Ustaw przypomnienie o rotacji (kwartalnie lepsze niż nigdy) i ustal procedurę awaryjnego unieważniania.

Jeśli budujesz z generatora no‑code, który produkuje prawdziwy kod, traktuj generację/eksport jako zadanie pierwszej klasy CI. Na przykład AppMaster (appmaster.io) generuje backendy w Go, web w Vue3 i aplikacje mobilne w Kotlin/SwiftUI, więc pipeline może regenerować kod przy zmianie, a potem budować tylko dotknięte cele.

Gdy masz flow, któremu zespół ufa, ustaw go jako domyślny dla nowych repo i trzymaj go nudnym: jasne wyzwalacze, przewidywalni runnerzy, ścisłe sekrety i wydania uruchamiane tylko wtedy, gdy naprawdę chcesz.