CI/CD 파이프 라인: GitHub 액션, GitLab CI

CI/CD 파이프 라인: GitHub 액션, GitLab CI

1) CI/CD 작업 및 플랫폼 공간

• 릴리스 속도 및 예측 가능성 (짧은 리드 타임).
• 품질 (자동 테스트, 정적/동적 분석).
• 공급망 보안 (아티팩트 서명, 액세스 제어).
• 신뢰성 (카나리아 예금, 빠른 롤백).
• 관찰 가능성 (각 단계의 추적 및 측정 항목).

주요 원칙: "코드로서의 파이프 라인", 불변의 아티팩트, "한 번 빌드 - 많이 실행", "시프트 왼쪽 보안", "왼쪽 특권", 결정 론적 어셈블리.

2) 컨베이어의 건축 패턴

스테이지 게이트: 빌드 → 테스트 → 보안 → 패키지 → 배포 → 배포 후 점검.
팬 아웃/팬 인: 결과가 연결된 병렬 행렬 어셈블리 (언어/플랫폼).
프로모션: 동일한 아티팩트가 환경 (dev→ stage → prod) 을 통해 프로모션되며 재 조립되지 않습니다.

트렁크 기반 + 짧은 브랜치: 드리프트 최소화, PR/화면에 대한 자동 점검

재사용 가능: 재사용 가능한 워크 플로우 GitLab: 포함/자식 파이프 라인).
GitOps (옵션): "어셈블리" 및 "전달" 분리 (Argo CD/Flux 모니터 선언적 리포 환경).

3) 공급망 보안

식별: 러너에서 클라우드까지 OIDC 페더레이션 (수명이 긴 키없이).
비밀: 중앙 집중식 스토리지, 컨텍스트 제한, 로깅 금지.
아티팩트/컨테이너 (cosign/Sigstore) 의 서명, 입장 제어의 서명 검증.
SBOM (CycloneDX/SPDX) 및 SCA, SAST/DAST/컨테이너 스캔- "필수 게이트".
정치인: 특권 컨테이너를 금지하는 "최신" IaC/선언문에 대한 OPA/Confest.
러너의 격리: 개인 네트워크의 프로드 러너, 공개 인터넷에서 나가는 액세스를 분리합니다.

4) GitHub 조치-구조 및 실습

4. 워크 플로 구조 1 개

'.github/workflows/.yml' -три

표준화를위한 재사용 가능한 워크 플로 (린터, SCA, 컨테이너 어셈블리, 배포).

4. 2 예: OIDC 및 이미지 서명이있는 다단계 파이프 라인

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

• OIDC에서 '권한' 이 최소화되었습니다. 'id-tocker: 쓰기' 가 활성화되었습니다.
• '동시성' 은 승인자와 탭으로 환경을 보호하여 경주를 방지합니다.
• SLO를 통한 트래픽 및 자동 롤백의 카나리아 포함.

4. 3 재사용 가능한 워크 플로 (호출 예)

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

5) GitLab CI-구조 및 실습

5. 1 기본 구조

'.gitlab-ci. 뿌리에서 yml '; 주요 엔티티: '단계', '작업', '규칙', '요구', '아티팩트', '환경', '수동'.
재사용: '포함:' (로컬/원격 패턴), 복잡한 모노 레포를위한 자식/부모 파이프 라인.

5. 2 예: 행렬, 캐시, 서명, 환경 및 승인

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

• '병렬. 행렬 '은 행렬 어셈블리를 시뮬레이션합니다.
• '아티팩트' + 테스트 보고서.
• 승인을위한 'on _ stop', 매뉴얼: manual '을 사용한 환경.
• 이미지 구축을위한 DIND (더 나은-k8 러너의 Kaniko/BuildKit).

5. 3 개의 아동 파이프 라인 및 단일 포함

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 및 멀티 서비스

디렉토리 기반 소유권: CODEOWNERS 및 경로 별 테스트 범위.
증분 구축: 영향을받는 패키지/차트 식별; 경로 키로 캐시하고 파일을 잠그십시오.
동적 파이프 라인: 변경된 구성 요소에 대해서만 하위 파이프 라인/' workflow _ call '이 실행됩니다.
버전: 각 모듈의 준수, 릴리스 단계의 변경 로그.

7) 캐싱 및 가속

콘텐츠 주소 캐시 (해시 파일/잠금 파일).
종속성 및 아티팩트에 대한 별도의 캐시.
따뜻한 러너 이미지 (툴체인, SDK).
로컬 패킷 미러 (npm/pip/maven) 및 컨테이너 레지스트리 캐시.

8) 릴리스 전략 및 롤백

카나리아: 트래픽 비율이 점차 증가합니다. SLO 분해 중 자동 정지.
Blue-Green: 병렬 스택, 즉시 전환.

그림자: 클라이언트에 영향을주지 않고 중복 요

기능 플래그: 릴리스 레벨이 아닌 플래그 레벨에서의 롤아웃.
롤백: 명확한 원 버튼 스크립트, 아티팩트 버전은 릴리스 메타 데이터에 저장됩니다.

9) 인프라 및 GitOps

IaC: Terraform/Ansible/Helm은 별도의 repos로 관리됩니다. 게이트로서의 코드 정책.
GitOps-contour: Argo CD/Flux는 환경의 선언문으로 repo를 관찰합니다. 파이프 라인은 Git에서 아티팩트 및 업데이트 버전 만 만듭니다.
장점: Git를 통한 명확한 환경 변화, demempotency, 표준 롤백의 이력.

10) CI/CD의 관찰 가능성

DORA 지표: 고갈 속도, 커밋에서 생산까지의 시간, 고장률, MTTR.
원격 측정: 작업 대기 시간, 단계 지속 시간, 캐시의 적중률, 벗겨진 테스트 빈도.
보안 로그: 누가 출시를 시작했는지, 어떤 게이트를 통과했는지, 예외가 발행되었습니다.

11) 액세스 제어 및 승인

지점 보호 및 필수 점검.
환경 승인: 무대/prod에 별도의 승인 목록.
수동 단계, 세션 로깅을위한 JIT 액세스.
직무 분리: "코드 작성", "승인", "릴리스" 에 대한 다른 역할.

12) 빈번한 오류 (패턴 방지)

OIDC 역할 대신 리포 비밀의 수명이 긴 클라우드 키.
무대와 prod에 대해 다른 아티팩트를 조립합니다 ("빌드 한 번" 위반).
'최신' 태그와 변경 가능한 이미지.
단계 로그 (비활성화 마스킹) 에 비밀을 게시합니다.
생산 배포를위한 하나의 일반적인 공공 러너.
보안 "게이트" (SAST/SCA/Policy) 및 사후 배치 점검 부족.

13) 구현 점검표 (0-60 일)

0-15 일

트렁크 기반, PR/MR 규칙, 필수 정적 검사 설정.
클라우드에 OIDC 페더레이션 사용; 최소한의 '권한'.
포스트 러너: 공개-CI, 비공개-CD.

16-30 일

SBOM, 이미지 서명 추가; 클러스터-서명 검증.
카나리아/청록색 입력; SLO에 의한 자동 롤백.
종속성과 인공물, 따뜻한 이미지의 캐시.

31-60 일

별도의 조립 및 배송 (GitOps), 코드 정책 게이트.
파이프 라인 저하에 대한 DORA 지표 및 경고를 설정하십시오.
모든 서비스에 대한 템플릿 파이프 라인 (재사용 가능/자식).

14) 실용적인 신뢰성 팁

작고 빠른 파이프 라인을 지원하십시오 (PR 신호 10-12 분 전).
벗겨지기 쉬운 테스트: 검역 태그 + 병렬 수정.
CI 아티팩트를 혼합하지 말고 아티팩트를 해제하십시오. 저장 메타 데이터 (커밋, 시간, SBOM, 서명).
개발자에게 파이프 라인 단계 (dev- prod parity) 와 동일한 로컬 스크립트를 제공하십시오.

15) 재사용 템플릿

15. 1 GitHub 조치-보안 재사용 가능한 워크 플로 (단순화)

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-템플릿 배포 (단순화) 포함

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) 결론

GitHub Actions 및 GitLab CI는 빠르고 안전한 코드 → prod 루프를위한 성숙한 메커니즘을 제공합니다. 성공의 핵심은 표준화 및 보안입니다. 키, 서명 및 SBOM 대신 OIDC, 품질 게이트, 프로모션이있는 단일 아티팩트, GitOps 배송 및 DORA를 통한 관찰 가능성. 제품으로 파이프 라인을 구축하십시오: 측정, 단순화, 속도 향상 및 릴리스는 이벤트가 아닌 집안일이됩니다.