Jak skonfigurować potok CI/CD z GitHub Actions – Poradnik

CI/CD Pipeline z GitHub Actions: Kompletny przewodnik konfiguracji

CI/CD Pipeline z GitHub Actions: Kompletny przewodnik konfiguracji

We współczesnym tworzeniu oprogramowania ręczne testowanie kodu i uruchamianie skryptów wdrożeniowych po każdej zmianie to wąskie gardło, które spowalnia dostarczanie i wprowadza błędy ludzkie. Pipeline CI/CD automatyzuje cały ten proces: od testowania kodu po jego wdrożenie na produkcji. Ten przewodnik nauczy Cię konfigurować pipeline CI/CD za pomocą GitHub Actions — potężnej i zintegrowanej platformy automatyzacji — wykorzystując praktyczne przykłady w YAML, abyś mógł dostarczać kod szybciej i bardziej niezawodnie.

Czego się nauczysz

Pod koniec tego przewodnika zrozumiesz podstawowe koncepcje ciągłej integracji i ciągłego wdrażania (CI/CD) oraz będziesz w stanie zaimplementować wieloetapowy pipeline za pomocą GitHub Actions. Nauczysz się pisać przepływy pracy do automatycznego testowania, budowania obrazów Docker i wdrażania aplikacji. Otrzymasz gotowy działający kod w YAML do testowania, budowania i wdrażania własnych projektów — niezależnie od tego, czy są to aplikacje w Pythonie, Node.js, czy aplikacje konteneryzowane.

Podstawy GitHub Actions

GitHub Actions to platforma automatyzacji sterowana zdarzeniami, wbudowana bezpośrednio w repozytoria GitHub. Umożliwia uruchamianie zautomatyzowanych przepływów pracy, inicjowanych przez zdarzenia takie jak push, pull_request lub release. W swej istocie przepływ pracy jest definiowany w pliku YAML, znajdującym się w katalogu .github/workflows/, i składa się z jednego lub kilku zadań, które domyślnie są wykonywane równolegle, z których każde zawiera szereg kroków.

Kluczowe komponenty

• Zdarzenie (on): Wyzwalacz uruchamiający przepływ pracy, np. push do określonej gałęzi lub pull_request.
• Wykonawca (runs-on): Maszyna, na której wykonywane jest zadanie. ubuntu-latest to najczęstszy i zalecany wybór ze względu na wydajność i szeroką dostępność oprogramowania.
• Kroki: Poszczególne zadania wewnątrz zadania. Mogą to być skrypty shell (run) lub gotowe akcje (uses) z Marketplace GitHub.
• Akcje: Wielokrotnego użytku bloki kodu, np. actions/checkout@v4 do klonowania repozytorium lub actions/setup-node@v4 do instalacji Node.js.

Podstawowy przepływ pracy na początek

Najprostszy przepływ pracy można uruchamiać przy każdym pushu. Utwórz plik .github/workflows/main.yml, aby wykonać podstawowe polecenie "Hello World".

name: example
on: push
jobs:
  greeting:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello, CI/CD World!"

Po zatwierdzeniu i wysłaniu tego pliku do repozytorium będziesz mógł zobaczyć wynik wykonania zadania na karcie "Actions" swojego repozytorium GitHub.

Tworzenie kompleksowego pipeline CI

Część "CI" pipeline gwarantuje, że zmiany kodu są automatycznie testowane i weryfikowane przed scaleniem. Zazwyczaj obejmuje to linting, sprawdzanie typów i uruchamianie testów jednostkowych.

Plik przepływu pracy CI

Utwórz .github/workflows/ci.yml. Ten przepływ pracy uruchamia się przy każdym push i pull_request do gałęzi main. Poniższy przykład demonstruje pełny pipeline dla projektu w Node.js, ale wzorzec ma zastosowanie również do innych języków, np. Python z actions/setup-python.

name: CI Pipeline

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

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint

  test:
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm test

  build:
    runs-on: ubuntu-latest
    needs: [lint, test]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run build

Wyjaśnienie kluczowych funkcji

1. Buforowanie zależności: Opcja cache: 'npm' w actions/setup-node znacznie przyspiesza przepływ pracy, ponownie wykorzystując zależności z poprzednich uruchomień.
2. Zależności zadań: Słowo kluczowe needs określa kolejność wykonywania. Na przykład zadanie build uruchamia się tylko po pomyślnym wykonaniu zadań lint i test. Zapobiega to marnowaniu czasu na budowanie zepsutego kodu.
3. Zmienne środowiskowe: Dla takich usług jak bazy danych można zdefiniować zmienne środowiskowe. Na przykład zadanie test może uruchomić kontener usługi PostgreSQL i użyć env do połączenia się z nim.

Zaawansowane scenariusze: wdrożenia konteneryzowane i wielośrodowiskowe

W przypadku nowoczesnych aplikacji pipeline często obejmuje budowanie obrazów kontenerów i ich wdrażanie. Poniższa tabela opisuje typowe strategie wdrażania i ich wyzwalacze.

Porównanie wyzwalaczy wdrożenia

Strategia	Wyzwalacze wdrożenia	Do czego najlepiej się nadaje
Oparta na gałęziach	push do main	Ciągłe wdrażanie najnowszego kodu deweloperskiego.
Oparta na tagach	push nowego tagu (np. v1.0.0)	Wydanie stabilnego, wersjonowanego oprogramowania na produkcję.
Oparta na wydaniach	Publikacja release na GitHub	Oficjalne wydania produktu, które również generują notatki o wydaniu.

Przykład: wdrażanie kontenera Docker za pomocą przepływu pracy CI/CD

Ten kompleksowy przykład demonstruje pipeline, który testuje aplikację w Pythonie, buduje obraz Docker i wysyła go do rejestru. Wykorzystuje serię oficjalnych akcji Docker do bezpiecznej i wydajnej budowy.

Utwórz .github/workflows/deploy.yml:

name: Complete CI/CD Pipeline

on:
  push:
    branches: [ main ]
  release:
    types: [published]

env:
  DOCKER_HUB_USERNAME: ${{ secrets.DOCKER_HUB_USERNAME }}
  DOCKER_HUB_TOKEN: ${{ secrets.DOCKER_HUB_TOKEN }}
  IMAGE_NAME: my-app

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v4
        with:
          python-version: '3.9'
      - run: pip install -r requirements.txt
      - run: pytest

  build-and-push:
    runs-on: ubuntu-latest
    needs: test
    if: github.event_name == 'push' || github.event_name == 'release'
    steps:
      - uses: actions/checkout@v4
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ env.DOCKER_HUB_USERNAME }}
          password: ${{ env.DOCKER_HUB_TOKEN }}
      - name: Extract metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.DOCKER_HUB_USERNAME }}/${{ env.IMAGE_NAME }}
          tags: |
            type=ref,event=branch
            type=semver,pattern={{version}}
            type=raw,value=latest,enable={{is_default_branch}}
      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

  deploy:
    runs-on: ubuntu-latest
    needs: build-and-push
    if: github.event_name == 'release'
    steps:
      - name: Execute Deployment Script
        run: |
          echo "Deploying image ${{ env.DOCKER_HUB_USERNAME }}/${{ env.IMAGE_NAME }}:${{ github.event.release.tag_name }}"

Ważne: zarządzanie sekretami

Aby powyższy przepływ pracy działał, należy bezpiecznie przechowywać dane uwierzytelniające w repozytorium GitHub. Przejdź do Settings > Secrets and variables > Actions i dodaj następujące sekrety:

1. DOCKER_HUB_USERNAME: Twoja nazwa użytkownika Docker Hub.
2. DOCKER_HUB_TOKEN: Osobisty token dostępu Docker Hub z uprawnieniami do odczytu i zapisu.

⚠️ Ostrzeżenie bezpieczeństwa: Nigdy nie wpisuj haseł, tokenów ani innych poufnych danych bezpośrednio do plików YAML. Zawsze używaj sekretów GitHub, które są szyfrowane i dostępne tylko podczas wykonywania przepływu pracy.

Często zadawane pytania

Jakie są pierwsze kroki do skonfigurowania pipeline CI/CD z GitHub Actions?

Na początek utwórz katalog .github/workflows w swoim repozytorium. Wewnątrz utwórz plik YAML (np. ci.yml) i zdefiniuj name, on (zdarzenia wyzwalające, takie jak push) oraz jobs (zadania do wykonania). Zatwierdź i wyślij ten plik, aby uruchomić pierwszy zautomatyzowany przepływ pracy.

Czy mogę używać GitHub Actions do uruchamiania testów w pull request?

Tak, testowanie w pull request to podstawowy przypadek użycia. Ustawiając wyzwalacz on na pull_request dla gałęzi main, przepływ pracy będzie automatycznie uruchamiany przy każdym nowym pull request, zapewniając jakość kodu przed scaleniem.

Jak zbudować i wysłać obraz Docker za pomocą przepływu pracy GitHub Actions?

Możesz użyć oficjalnych złożonych akcji, takich jak docker/login-action, docker/setup-buildx-action i docker/build-push-action. Upraszcza to proces, automatycznie obsługuje uwierzytelnianie i zawiera funkcje takie jak buforowanie budowy i budowanie wieloplatformowe.

Czy można wdrażać na GitHub Pages za pomocą GitHub Actions?

Tak. Możesz użyć akcji społecznościowej JamesIves/github-pages-deploy-action. Skonfiguruj ją, podając folder z gotową witryną, a wykona ona operacje git w celu zatwierdzenia i wysłania zmian do gałęzi gh-pages.

Jaka jest różnica między wyzwalaczami zdarzeń push i release?

Zdarzenie push uruchamia przepływ pracy po wysłaniu kodu do określonej gałęzi. Zdarzenie release uruchamia się po opublikowaniu wydania na GitHub. push jest zwykle używany do CI i wdrażania na staging, a release jest często używany do wdrażania na produkcję.

Źródła

• Set up GitHub Actions CI/CD pipeline · Issue #176 (Praktyczne przykłady YAML dla CI, E2E i wdrożeń)
• DevOps: Set up GitHub Actions CI/CD pipeline · Issue #19 (Demonstruje linting, sprawdzanie typów i weryfikację budowy)
• GitHub - kamrun111/GitHubActionTest (Prosty przykład CI/CD w Pythonie dla początkujących)
• @jamesives/github-pages-deploy-action (Dokumentacja wdrażania na GitHub Pages)
• GitHub - CarlosQuintero8/cicdsimulation (Demonstruje wieloetapowy pipeline z testowaniem, budową i wdrażaniem na GitHub Pages)
• GitHub - anuragstark/Py-app-CI-CD-Pipeline- (Kompleksowy przewodnik obejmujący wdrażanie z Docker i Minikube)
• Automated CI/CD with GitHub Actions, starting from scratch (Przewodnik krok po kroku tworzenia przepływów pracy CI/CD)
• Extend App with GitHub Actions · AccelByte Documentation (Przykład wdrożenia inicjowanego zdarzeniem wydania)
• Configure CI/CD for your C++ application · Docker Docs (Demonstruje konfigurację GitHub Actions z Docker Hub)
• Hello CI World · HSF Training (Podstawowy samouczek tworzenia i uruchamiania pierwszego przepływu pracy)

— Editorial Team