CI/CD dla .NET — pierwszy pipeline w GitHub Actions

Po opanowaniu Gita naturalny następny krok to automatyzacja tego, co robiłbyś ręcznie po każdym pushu: budowanie projektu, uruchomienie testów, publikacja. To właśnie CI/CD — Continuous Integration (automatyczne budowanie i testowanie każdej zmiany) i Continuous Deployment (automatyczne wdrażanie zweryfikowanej zmiany).

Gdzie żyje pipeline

GitHub Actions czyta konfigurację z pliku YAML w katalogu .github/workflows/ w Twoim repozytorium — np. .github/workflows/ci.yml. Każdy push albo Pull Request może automatycznie uruchomić zdefiniowany tam zestaw kroków.

Pierwszy pipeline — build i test

name: CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout kodu
        uses: actions/checkout@v4

      - name: Instalacja .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '9.0.x'

      - name: Przywróć zależności
        run: dotnet restore

      - name: Zbuduj projekt
        run: dotnet build --no-restore --configuration Release

      - name: Uruchom testy
        run: dotnet test --no-build --configuration Release

on: definiuje, kiedy pipeline się uruchamia — tutaj przy każdym pushu do main i przy każdym Pull Requeście do main. runs-on: ubuntu-latest uruchamia zadanie na czystej maszynie wirtualnej w chmurze GitHub — nie na Twoim komputerze.

Testy jako brama (gate)

Kluczowa właściwość tego pipeline’u: jeśli dotnet test zwróci błąd (choćby jeden test xUnit nie przejdzie), cały krok — a razem z nim cały workflow — kończy się niepowodzeniem. GitHub pokaże czerwony X przy commicie i (jeśli to Pull Request) zablokuje możliwość scalenia, dopóki testy nie przejdą. To zamienia “pamiętaj, żeby uruchomić testy przed pushem” w regułę wymuszaną automatycznie, niezależnie od tego, czy ktoś o tym pamięta.

Publikacja artefaktu

      - name: Publikuj aplikację
        run: dotnet publish -c Release -o ./publish

      - name: Zapisz artefakt
        uses: actions/upload-artifact@v4
        with:
          name: aplikacja
          path: ./publish

dotnet publish tworzy gotowy do wdrożenia zestaw plików (skompilowane DLL-e, pliki konfiguracyjne), a upload-artifact zapisuje go jako pobieralny wynik danego uruchomienia pipeline’u — przydatne, żeby mieć dokładnie tę wersję, która przeszła testy, gotową do ręcznego albo automatycznego wdrożenia.

Sekrety — dane, których nie wpisujesz do YAML

      - name: Wdróż na serwer
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
        run: ./deploy.sh

Hasła, tokeny API czy connection stringi nigdy nie trafiają bezpośrednio do pliku YAML (który jest publiczny w repozytorium). Zamiast tego dodajesz je w ustawieniach repozytorium (Settings → Secrets and variables → Actions) i odwołujesz się do nich przez ${{ secrets.NAZWA }} — GitHub wstrzykuje wartość w czasie działania, nigdy nie zapisując jej w logach ani w historii Gita.

Od CI do CD — automatyczne wdrożenie

Powyższy pipeline to czyste CI (build + test). Żeby dodać CD (automatyczne wdrożenie), rozszerzasz workflow o kolejny job, który uruchamia się dopiero po sukcesie poprzedniego:

  deploy:
    needs: build-and-test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - name: Wdróż na produkcję
        run: echo "Tutaj komendy wdrożeniowe (Azure, Docker, itd.)"

needs: build-and-test gwarantuje, że wdrożenie nigdy nie uruchomi się, jeśli build albo testy zawiodły. if: github.ref == 'refs/heads/main' ogranicza wdrożenie tylko do zmian trafiających bezpośrednio do głównej gałęzi — Pull Requesty budują się i testują, ale nie wdrażają automatycznie.

Podsumowanie

CI/CD w .NET sprowadza się do jednego pliku YAML w .github/workflows/, który definiuje, co ma się wydarzyć po każdym pushu: pobranie kodu, instalacja .NET, dotnet restore/build/test. Testy działają jako automatyczna brama — nieudany test blokuje merge i wdrożenie, zanim ktokolwiek zdąży to przeoczyć ręcznie. Dodanie publikacji artefaktu i kroku wdrożenia (uzależnionego od sukcesu poprzednich kroków) zamienia czyste CI w pełne CI/CD — od pushu do działającej aplikacji, bez ręcznej interwencji.