Dostrajanie wydajności potoków
Zidentyfikują Państwo wąskie gardła i zastosują zaawansowane techniki optymalizacji szybkości wykonywania oraz zużycia zasobów workflows GitHub Actions.
Dostrajanie wydajności potoków to bezpłatna lekcja CI/CD with GitHub Actions & DevOps Pipelines na CoddyKit. To lekcja 2 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej CI/CD with GitHub Actions & DevOps Pipelines, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs CI/CD with GitHub Actions & DevOps Pipelines zawiera 4 lekcji w sumie.
Zwiększanie szybkości potoku
Witamy w lekcji dostrajania wydajności potoku! We współczesnym procesie wytwarzania oprogramowania szybkie potoki CI/CD mają kluczowe znaczenie dla uzyskiwania szybkiej informacji zwrotnej i efektywnego wykorzystania zasobów.
Wolne potoki marnują czas i pieniądze. W tej lekcji pozna Pan/Pani zaawansowane techniki identyfikowania wąskich gardeł i znacznego przyspieszania przepływów pracy GitHub Actions.
Znajdowanie wąskich gardeł przepływu pracy
Zanim zacznie Pan/Pani optymalizować, trzeba wiedzieć, *co* należy zoptymalizować. GitHub Actions udostępnia doskonałe narzędzia do wskazywania powolnych kroków lub zadań.
- Interfejs GitHub: Wyświetl logi uruchomień przepływów pracy. Widok osi czasu wyraźnie pokazuje, ile trwało każde zadanie i każdy krok.
- Podsumowania zadań: Należy szukać kroków o nietypowo długim czasie trwania.
- Logi akcji: Szczegółowe logi mogą ujawnić konkretne polecenia lub procesy, które zajmują najwięcej czasu.
Należy skupić się na krokach, które niezmiennie trwają najdłużej.
Równoległe uruchamianie niezależnych zadań
Jeśli części przepływu pracy nie zależą od siebie, należy uruchamiać je jednocześnie! To prosty, ale skuteczny sposób na skrócenie całkowitego czasu wykonywania.
Należy zdefiniować wiele zadań najwyższego poziomu w przepływie pracy. GitHub Actions domyślnie uruchomi je równolegle, o ile nie zostaną określone zależności needs między nimi.
name: Parallel Jobs Example
on: [push]
jobs:
build-frontend:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build Frontend
run: echo "Building frontend..."
build-backend:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build Backend
run: echo "Building backend..."
Optymalizacja akcji checkout
Akcja actions/checkout pobiera kod repozytorium. W przypadku dużych repozytoriów lub repozytoriów z rozbudowaną historią może to trwać długo. Można to zoptymalizować:
- Płytkie klonowanie: Należy użyć
fetch-depth: 1, aby pobrać tylko najnowszy commit, co w przypadku większości zadań CI/CD pozwala znacznie skrócić czas. - Wybiórcze pobieranie: Jeśli potrzebny jest tylko podzbiór plików, warto rozważyć sparse checkout, choć jego konfiguracja bywa bardziej złożona.
Należy unikać fetch-depth: 0, chyba że jest to absolutnie konieczne, ponieważ powoduje pobranie całej historii.
name: Optimized Checkout
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 1 # Only fetch the latest commit
- name: Run Build
run: echo "Code checked out and building..."
Zmniejszanie rozmiaru artefaktów kompilacji
Jeśli przepływ pracy przesyła lub pobiera artefakty, takie jak skompilowane pliki binarne lub raporty z testów, ich rozmiar bezpośrednio wpływa na wydajność.
Aby przyspieszyć działanie:
- Należy uwzględniać tylko niezbędne pliki: Nie należy przesyłać tymczasowych katalogów kompilacji ani zbędnych logów.
- Należy kompresować artefakty: Jeśli to możliwe, przed przesłaniem należy skompresować duże artefakty. Akcja
actions/upload-artifactautomatycznie obsługuje kompresję, ale warto zadbać o minimalny zestaw plików źródłowych.
Filtrowanie ścieżek na potrzeby wydajności
Nie każda zmiana kodu musi uruchamiać każde zadanie. Należy używać filtrowania ścieżek, aby uruchamiać zadania tylko wtedy, gdy zmodyfikowane zostaną odpowiednie pliki.
Jest to szczególnie przydatne w większych repozytoriach, w których zmiana w dokumentacji nie powinna uruchamiać pełnej kompilacji backendu.
Należy określić paths lub paths-ignore w wyzwalaczu on przepływu pracy.
name: Path Filter Example
on:
push:
paths:
- 'frontend/**'
- 'shared/**'
jobs:
build-frontend:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build Frontend
run: echo "Frontend files changed, building..."
Szybsze wykonawcy i przydzielanie zasobów
Maszyny wirtualne (wykonawcy) uruchamiające przepływy pracy są dostępne w różnych rozmiarach i typach. W przypadku zadań intensywnie korzystających z procesora bardziej wydajny wykonawca może znacznie skrócić czas wykonywania.
- Więksi wykonawcy hostowani przez GitHub: GitHub oferuje większych wykonawców, np.
ubuntu-latest-xlarge, do bardziej wymagających obciążeń. - Wykonawcy hostowani samodzielnie: Jeśli potrzebny jest bardzo konkretny sprzęt lub chcą Państwo zminimalizować opóźnienia sieciowe w dostępie do zasobów wewnętrznych, wykonawców hostowanych samodzielnie można zoptymalizować pod kątem dokładnych wymagań.
Zaawansowane strategie buforowania
Buforowanie zależności, takich jak pakiety npm lub artefakty Maven, jest niezbędne. Oprócz podstawowego buforowania warto zastosować następujące wskazówki:
- Precyzyjne klucze pamięci podręcznej: Należy używać bardziej szczegółowych kluczy, aby unikać niepotrzebnych chybień pamięci podręcznej. Można na przykład uwzględnić skrót konkretnego pliku blokady i system operacyjny.
- Wiele pamięci podręcznych: Nie należy umieszczać wszystkiego w jednej dużej pamięci podręcznej. Oddzielne pamięci podręczne dla różnych typów zależności, np. node_modules i pakietów pip, mogą poprawić współczynnik trafień.
- Klucze przywracania: Należy używać
restore-keys, aby w przypadku chybienia głównego klucza wypróbować wiele innych kluczy, zwiększając szansę na częściowe trafienie.
name: Advanced Caching
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Cache Node Modules
uses: actions/cache@v4
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: | # Try less specific keys if primary misses
${{ runner.os }}-node-
- name: Install Dependencies
run: npm ci
Zoptymalizuj ten przepływ pracy
Rozważmy przepływ pracy, który kompiluje kod frontend i backend. Obecnie zadania są wykonywane sekwencyjnie, a checkout pobiera całą historię. Które dwie zmiany znacząco poprawiłyby jego wydajność?
name: Inefficient Workflow
on: [push]
jobs:
build-all:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install Frontend Deps
run: npm install
- name: Build Frontend
run: npm run build
- name: Install Backend Deps
run: pip install -r requirements.txt
- name: Build Backend
run: python setup.py build
Podsumowanie: dostrajanie pod kątem szybkości
Opanował(a) Pan/Pani skuteczne techniki optymalizowania przepływów pracy GitHub Actions!
- Identyfikowanie wąskich gardeł: Należy korzystać z interfejsu GitHub i logów.
- Równoległe uruchamianie zadań: Należy wykonywać niezależne zadania jednocześnie.
- Optymalizacja checkout: Należy używać płytkich klonów.
- Ograniczanie artefaktów: Należy utrzymywać mały rozmiar przesyłanych i pobieranych danych.
- Filtrowanie ścieżek: Należy uruchamiać zadania tylko wtedy, gdy zmienią się odpowiednie pliki.
- Szybsi wykonawcy: Należy dobierać odpowiednie zasoby wykonawców.
- Zaawansowane buforowanie: Należy używać precyzyjnych kluczy i wielu pamięci podręcznych.
Zastosowanie tych strategii pozwoli przyspieszyć potoki, zwiększyć ich wydajność oraz zaoszczędzić cenny czas i zasoby.
Często zadawane pytania
Czy lekcja „Dostrajanie wydajności potoków” jest bezpłatna?
Tak — pełny tekst „Dostrajanie wydajności potoków” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu CI/CD with GitHub Actions & DevOps Pipelines, przejdź na CoddyKit PRO. Kurs CI/CD with GitHub Actions & DevOps Pipelines zawiera 4 lekcji w sumie.
Co nauczysz się w „Dostrajanie wydajności potoków”?
Zidentyfikują Państwo wąskie gardła i zastosują zaawansowane techniki optymalizacji szybkości wykonywania oraz zużycia zasobów workflows GitHub Actions. Ćwiczysz CI/CD with GitHub Actions & DevOps Pipelines z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.
Czy potrzebuję doświadczenia, aby zacząć CI/CD with GitHub Actions & DevOps Pipelines?
Nie wymagamy żadnego doświadczenia. CI/CD with GitHub Actions & DevOps Pipelines w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 2 z 4.
Ile czasu zajmuje lekcja „Dostrajanie wydajności potoków”?
Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.
Czy mogę pisać i uruchamiać kod w tej lekcji CI/CD with GitHub Actions & DevOps Pipelines?
Tak. Każda lekcja CI/CD with GitHub Actions & DevOps Pipelines zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.
Wszystkie lekcje w tym kursie
- Metryki DORA i kondycja CI/CD
- Dostrajanie wydajności potoków
- Przyszłe trendy w automatyzacji DevOps
- Optymalizacja kosztów CI/CD i efektywności runnerów