Rurociągi CI/CD: GitHub Actions, GitLab CI

Rurociągi CI/CD: GitHub Actions, GitLab CI

1) Zadanie CI/CD i przestrzeń platformowa

• Szybkość i przewidywalność zwolnień (krótki czas realizacji).
• Jakość (testy automatyczne, analiza statyczna/dynamiczna).
• Bezpieczeństwo łańcucha dostaw (podpisanie artefaktu, kontrola dostępu).
• Niezawodność (depozyty kanaryjskie, szybki zwrot).
• Obserwowalność (ślad i mierniki na każdym etapie).

Kluczowe zasady: „rurociąg jako kod”, niezmienne artefakty „, zbudować raz - uruchom wiele”, „przesunięcie-lewe zabezpieczenie”, „lewy przywilej”, zespoły deterministyczne.

2) Wzory architektoniczne przenośników

Stage-gate: build → test → bezpieczeństwo → pakiet → wdrożenie → po wdrożeniu kontroli.
Wentylator/wentylator: równoległe zespoły matryc (języki/platformy) z koatenacją wyników.
Promocja: ten sam artefakt jest promowany przez środowisko (dev → etap → prod), a nie reassembled.
Bagażnik + krótkie gałęzie: minimalizacja dryfu, zautomatyzowane kontrole PR/MR.
Wielokrotnego użytku: wielokrotnego użytku przepływy pracy GitLab: zawiera/child-pipelines).
GitOps (opcjonalnie): separacja „montażu” i „dostawy” (Argo CD/Flux monitor deklaracyjne środowiska repo).

3) Bezpieczeństwo łańcucha dostaw

Identyfikacja: Federacja OIDC od biegacza do chmury (bez długotrwałych klawiszy).
Sekrety: scentralizowana pamięć masowa, ograniczenia kontekstowe, zakaz rejestrowania.
Podpis artefaktów/pojemników (cosign/Sigstore), weryfikacja podpisu w kontroli wjazdu.
SBOM (CycloneDX/SPDX) i SCA, SAST/DAST/Container Scan - „obowiązkowa brama”.
Politycy: OPA/Conftest dla IaC/manifestów, „brak najnowszych”, zakaz uprzywilejowanych kontenerów.
Izolacja biegaczy: prod-runners w sieci prywatnej, oddzielny dostęp wychodzący z publicznego Internetu.

4) Działania GitHub - struktura i praktyki

4. 1 struktura przepływów pracy

„.github/workflows/.yml' - трибера (” na: push, pull_request, schedule, workflow_call').
Wielokrotnego użytku przepływy pracy do standaryzacji (liniowiec, SCA, montaż kontenera, wdrożenie).

4. 2 Przykład: rurociąg wielostopniowy z OIDC i sygnaturą obrazu

yaml name: ci-cd

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

permissions:
id-token: write  # для OIDC contents: read packages: write

jobs:
build_test_matrix:
runs-on: ubuntu-latest strategy:
matrix:
node: [18, 20]
os: [ubuntu-latest]
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4 with: { node-version: ${{ matrix. node }} }
- name: Cache npm uses: actions/cache@v4 with:
path: ~/.npm key: npm-${{ runner. os }}-${{ matrix. node }}-${{ hashFiles('/package-lock. json') }}
- run: npm ci
- run: npm run lint && npm test -- --ci

docker_build_sign:
runs-on: ubuntu-latest needs: build_test_matrix steps:
- uses: actions/checkout@v4
- name: Login to GHCR uses: docker/login-action@v3 with:
registry: ghcr. io username: ${{ github. actor }}
password: ${{ secrets. GITHUB_TOKEN }}
- name: Build image run:
docker build --pull --no-cache -t ghcr. io/org/app:${{ github. sha }}.
docker push ghcr. io/org/app:${{ github. sha }}
- name: Generate SBOM uses: anchore/syft-action@v0 with:
image: ghcr. io/org/app:${{ github. sha }}
format: cyclonedx-json output-file: sbom. json
- name: Cosign sign (OIDC)
uses: sigstore/cosign-installer@v3
- name: Sign image run:
cosign sign ghcr. io/org/app:${{ github. sha }} \
--yes \
--identity-token $ACTIONS_ID_TOKEN_REQUEST_TOKEN \
--rekor-url https://rekor. sigstore. dev

deploy_stage:
runs-on: ubuntu-latest needs: docker_build_sign environment:
name: stage url: https://stage. example. com steps:
- uses: actions/checkout@v4
- name: Assume cloud role via OIDC uses: aws-actions/configure-aws-credentials@v4 with:
role-to-assume: arn:aws:iam::123456789012:role/github-deployer aws-region: eu-central-1
- name: Helm deploy (canary 10%)
run:
helm upgrade --install app charts/app \
--set image. tag=${{ github. sha }} \
--set canary. enabled=true --set canary. traffic=10
- name: Smoke checks run:./scripts/smoke. sh

promote_prod:
runs-on: ubuntu-latest needs: deploy_stage environment:
name: production url: https://app. example. com concurrency: prod-release steps:
- name: Manual approval gate run: echo "Requires environment approvers in repo settings"
- name: Promote canary → 100% (blue-green)
run:
helm upgrade --install app charts/app \
--set image. tag=${{ github. sha }} \
--set canary. enabled=false
- name: Post-deploy checks & rollback on SLO breach run:./scripts/verify_or_rollback. sh

• 'permissions' są zminimalizowane, 'id-token: write' jest włączony dla OIDC.
• Środowiska z aprobatami i adresem URL, „concurrency” chroni przed wyścigami.
• Kanaryjskie włączenie ruchu i automatyczne rolki nad SLO.

4. 3 Wielokrotnego użytku (przykład wywołania)

yaml jobs:
security_suite:
uses: org/.github/.github/workflows/security. yml@v1 with:
severity_threshold: high

5) GitLab CI - Struktura i praktyki

5. 1 Struktura podstawowa

".gitlab-ci. yml' u źródła; kluczowe podmioty: „etapy”, „miejsca pracy”, „zasady”, „potrzeby”, „artefakty”, „środowiska”, „podręcznik”.
Ponowne użycie: 'zawierają:' (wzory lokalne/zdalne), rurociągi dziecięce/macierzyste dla złożonych monoroforów.

5. 2 Przykład: matryca, pamięć podręczna, podpis, środowiska i aprobaty

yaml stages: [lint, test, build, security, deploy]

variables:
DOCKER_TLS_CERTDIR: "" # docker: dind acceleration
IMAGE_TAG: $CI_COMMIT_SHA

lint:
stage: lint image: node:20 script:
- npm ci
- npm run lint cache:
key: "npm-${CI_COMMIT_REF_SLUG}"
paths: [node_modules/]
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"

test:
stage: test image: node:20 parallel:
matrix:
- NODE_VERSION: ["18", "20"]
script:
- nvm install $NODE_VERSION          true
- npm ci
- npm test -- --ci artifacts:
when: always reports:
junit: report. xml

build_image:
stage: build image: docker:26. 1 services: [ "docker:26. 1-dind" ]
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker build -t $CI_REGISTRY_IMAGE:$IMAGE_TAG.
- docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG artifacts:
expire_in: 1 week paths: [ "sbom. json" ]
after_script:
- syft $CI_REGISTRY_IMAGE:$IMAGE_TAG -o cyclonedx-json > sbom. json

security_scans:
stage: security image: alpine:3. 20 script:
- trivy image --exit-code 0 --severity HIGH,CRITICAL $CI_REGISTRY_IMAGE:$IMAGE_TAG rules:
- if: '$CI_COMMIT_BRANCH == "main"'

deploy_stage:
stage: deploy image: bitnami/kubectl:1. 30 environment:
name: stage url: https://stage. example. com on_stop: stop_stage script:
- kubectl set image deploy/app app=$CI_REGISTRY_IMAGE:$IMAGE_TAG -n stage
-./scripts/smoke. sh needs: [build_image, security_scans]
when: manual allow_failure: false

stop_stage:
stage: deploy image: bitnami/kubectl:1. 30 environment:
name: stage action: stop script:
- kubectl rollout undo deploy/app -n stage

deploy_prod:
stage: deploy image: alpine/k8s:1. 30. 2 environment:
name: production url: https://app. example. com rules:
- if: '$CI_COMMIT_BRANCH == "main"'
when: manual allow_failure: false script:
-./scripts/canary_traffic. sh 10
-./scripts/verify_or_rollback. sh

• "równolegle. matryca 'symuluje zespoły macierzy.
• „artefakty” + sprawozdania z badań.
• Środowiska z 'on _ stop', instrukcja obsługi 'when: manual' for approvals.
• DIND do budowy obrazu (lepiej - Kaniko/Kit w biegaczu k8s).

5. 3 Rurociągi dziecięce i w tym do monororepo

yaml include:
- local:.gitlab/ci/includes/security. yml
- project: org/platform/pipelines file: /k8s/deploy. yml ref: v1

stages: [prepare, component_a, component_b, deploy]

component_a:
stage: component_a trigger:
include:.gitlab/ci/component_a. yml strategy: depend

component_b:
stage: component_b trigger:
include:.gitlab/ci/component_b. yml strategy: depend

6) Monorepository i multiservice

Własność oparta na katalogu: CODEOWNERS i scoped testy według ścieżki.
Stopniowe budowanie: zidentyfikować dotknięte pakiety/wykresy; pamięci podręcznej za pomocą klawiszy ścieżki i plików blokady.
Rurociągi dynamiczne: rurociągi dla dzieci/„ workflow _ call ”uruchamiane tylko dla zmienionych elementów.
Wersioning: semver dla każdego modułu, changelog na etapie wydania.

7) Buforowanie i przyspieszenie

Bufory adresów treści (hashFiles/lockfile).
Oddzielna pamięć podręczna do zależności i artefaktów.
Wstępnie ciepłe obrazy (łańcuchy narzędzi, SDK).
Lokalne lustra pakietów (npm/pip/maven) i pamięć podręczna rejestru kontenerów.

8) Strategie uwolnienia i zwrot

Kanaryjskie: stopniowe zwiększanie odsetka ruchu; automatyczne zatrzymanie podczas degradacji SLO.
Niebiesko-zielony: równoległe stosy, natychmiastowe przełączanie.
Cień: duplikat żądań bez wpływu na klienta.
Flagi funkcji: rollout na poziomie flagi, a nie poziom zwolnienia.
Rollback: wyczyść skrypty z jednym przyciskiem, wersja artefaktu jest przechowywana w metadanych wydania.

9) Infrastruktura i gitopy

IaC: Terraform/Ansible/Helm są zarządzane w oddzielnych repo; Polityka jako kod jako brama.
GitOps-kontur: Argo CD/Flux obserwować repo z manifestami środowisk; rurociąg tworzy tylko artefakt i aktualizuje wersje w Git.
Zalety: jasna historia zmian w środowisku, idempotencja, standardowe rolki za pośrednictwem Git.

10) Obserwowalność CI/CD

Wskaźniki DORA: wskaźnik wyczerpania, czas od zobowiązania do produkcji, wskaźnik awarii, MTTR.
Telemetria: czas trwania kolejek pracy, czas trwania etapów, szybkość trafienia pamięci podręcznej, częstotliwość testów płatkowych.
Dzienniki bezpieczeństwa: kto zainicjował wydanie, które bramy zostały przekazane, które wyjątki zostały wydane.

11) Kontrola dostępu i zatwierdzanie

Ochrona oddziału i obowiązkowe kontrole.
Homologacje środowiskowe: oddzielne wykazy zatwierdzających na scenie/prod.
Dostęp do JIT dla czynności ręcznych, rejestrowanie sesji.
Rozdzielenie obowiązków: różne role dla „pisze kod”, „zatwierdza”, „zwalnia”.

12) Częste błędy (anty-wzorce)

Długotrwałe klawisze chmury w tajemnicach repo zamiast ról OIDC.
Montaż różnych artefaktów na scenę i prod (naruszenie „zbudować raz”).
'latest' tags i mutable images.
Publikowanie tajemnic w dziennikach kroków (maskowanie niezablokowane).
Jeden powszechnie działający podmiot zajmujący się produkcją.
Brak „bramy” bezpieczeństwa (SAST/SCA/Policy) i kontrole po wdrożeniu.

13) Lista kontrolna wdrażania (0-60 dni)

0-15 dni

Konfiguracja bagażnika, zasady PR/MR, obowiązkowe kontrole statyczne.
Włącz federację OIDC do chmury; minimalne 'porty'.
Biegacze pocztowi: publiczni - dla CI, prywatni - dla CD.

16-30 dni

Dodaj SBOM, podpis obrazu; Klaster - weryfikacja podpisu.
Wprowadź kanarka/niebiesko-zielony; auto-rollback przez SLO.
Pamięć podręczna zależności i artefaktów, przedciepłe obrazy.

31-60 dni

Oddzielny montaż i dostawa (GitOps), brama policy-as-code.
Ustanowienie mierników i wpisów DORA w celu degradacji rurociągów.
Rurociągi szablonowe (wielokrotnego użytku/dziecka) dla wszystkich usług.

14) Praktyczne wskazówki dotyczące niezawodności

Obsługiwać małe, szybkie rurociągi (10-12 minut przed sygnałem PR).
Zabij próbki płatkowe: znaczniki kwarantanny + równoległe poprawki.
Nie mieszać artefaktów CI i artefaktów uwalniania; przechowywać metadane (commit, czas, SBOM, podpisy).
Daj programistom lokalne skrypty identyczne z krokami rurociągu (dev-prod parity).

15) Szablony do ponownego użycia

15. 1 Działania GitHub - wielokrotnego użytku w zakresie bezpieczeństwa (uproszczony)

yaml name: security-suite on:
workflow_call:
inputs:
severity_threshold:
type: string required: false default: high jobs:
sast_sca:
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- run:./sec/sast. sh --threshold ${{ inputs. severity_threshold }}
- run:./sec/sca. sh --format cyclonedx-json --out sbom. json artifacts: # if using actions/upload-artifact
- sbom. json

15. 2 GitLab - dodaj rozmieszczenie szablonu (uproszczone)

yaml
.deployment_template:
image: alpine/k8s:1. 30 script:
- helm upgrade --install $APP charts/$APP --set image. tag=$IMAGE_TAG rules:
- if: '$CI_COMMIT_BRANCH == "main"'

16) Wniosek

GitHub Actions i GitLab CI zapewniają dojrzałe mechanizmy szybkiego i bezpiecznego kodu → prod pętli. Kluczem do sukcesu jest standaryzacja i bezpieczeństwo: OIDC zamiast kluczy, podpis i SBOM, bramy jakości, pojedynczy artefakt z promocją, dostawa GitOps i obserwowalność za pośrednictwem DORA. Budowa rurociągów jako produktu: Zmierzyć, uprościć, przyspieszyć - i wydania staną się chore, a nie wydarzenie.