준비 파이프 라인 및 릴리스

1) 스테이징 파이프 라인이 필요한 이유

• 조립 및 방출 재현성;
• 빠르고 예측 가능한 피드백;
• 위험 최소화 (프로그레시브 롤링, 피체 플래그, 롤백);
• 규정 준수 및 변경 제어.

2) 참조 공급 흐름 (높은 수준)

1. PR → 자동 점검 (보푸라기, 단위, SAST, 라이센스).
2. → 결정 론적 이미지/패키지, 서명 및 SBOM을 빌드하십시오.
3. PR 당 Ephemeral → 미리보기 환경에 대한 테스트.

• 이미지 증착;
• 계약, 통합, e2e 테스트;
• DAST/IAST, 회귀, 로딩 연기;
• 필요한 경우 수동 UAT/QA.
• 5. 릴리스 후보 (RC) → 동결 창 → Prod (카나리아/청록색).
• 6. SLO/오류 예산에 대한 배포 후 점검 및 자동 게시물.
• 7. Runbook/Changelog → 마감 릴리스 및 소급.

3) 표준화 된 YAML 파이프 라인 템플릿 (셔터 속도)

yaml
.ci/release.pipeline.yml stages: [verify, build, test, stage, approve, release, post]

verify:
- run: make lint test:unit sbom sast sca build:
- run:
docker build -t registry/app:$GIT_SHA.
cosign sign registry/app:$GIT_SHA oras push registry/sbom:$GIT_SHA sbom.json test:
- run: make test:contract test:integration
- run: make deploy:preview && make test:e2e stage:
- run: make deploy:staging IMAGE=registry/app:$GIT_SHA
- run: make test:e2e:staging && make dast approve:
manual gate: CAB/QA lead
- type: manual required_roles: [release_manager, qa_lead]
release:
- run: make release:canary TRAFFIC=5%
- run: make release:progressive STEPS="5,25,50,100"
post:
- run: make verify:slo && make notify && make create:changelog

4) 게이트 및 준비 기준 (품질 게이트)

코드 및 보안: 린트, 커버리지, SAST/SCA, 종속성 정책, 중요/높이 없음.
계약: 체계의 호환성 (API/이벤트), Pact/Buf 확인.
테스트: 단위/통합/e2e p- 임계 값, 안정성 (플레이크 속도).
연기: 예산 내에서 p95/p99, 열화 없음.
DAST/IAST: 민감한 경로에 대한 중요한 결과, 펜 테스트 시나리오가 없습니다.
관찰: 대시 보드/경고 "코드" 가 업데이트되고 런북이 첨부되었습니다.
CAB/UAT: 릴리스 창에서의 확인 (규제/비즈니스에서 요구하는 경우).

5) 릴리스 전략

Shadow/Traffic Mirroring-수동 트래픽은 사용자에게 영향을 미치지 않으면 서 새 버전으로

카나리아-트래픽 점유율 (5% → 25% → 50% → 100%) 의 점진적인 증가, SLO 및 이상에 대한 자동 롤 포워드/롤백.
Blue-Green-병렬 미디어; 즉석 스위치, 간단한 롤백.
기능 플래그 - 재배치없이 기능의 논리적 포함; "어두운 발사" 및 A/B 기능.
링 배치-지역/테넌트 별 파도.

6) 롤백 및 릴리스 보안 정책

트리거에 의한 자동 롤백: 오류율 증가, 임계 값 이상의 p95/TTFB, 5xx/타임 아웃 성장, DLQ 스파이크.
수동 롤백: 챕봇의 명령 '/롤백 <서비스> <sha> ', 릴리스 콘솔의 하나의 버튼.
동결 창: 중요한 이벤트 (토너먼트/피크 경기) 로 릴리스하는 것은 금지됩니다.
Changelog & Release Notes: PR, SemVer 태그, 구성 요소, 마이그레이션 생성.

7) 데이터베이스 마이그레이션 및 호환성

1. 호환되는 필드/인덱스 추가

2. 응용 프로그램 배포 (두 체계 모두에 대한 읽기/쓰기);

3. 배경 작업이있는 데이터 마이그레

4. 오래된 것을 삭제하

계획은 버전이 지정되고, dem 등원 이동이 가능하며, 준비 과정에서 건조 실행됩니다.

파괴적인 SQL 보호: 플래그/승인, 자동 백업 및 계획 확인이 필요합니다.

8) Ficheflags 및 점진적 활성화

별도의 ops 플래그 (안전한 작동 용) 및 제품 플래그.
청중 포함: 백분율, 지리, 세입자, 역할.
플래그 메트릭: 변환 영향, 대기 시간, 오류.
문제가있는 경우-플래그의 컨볼 루션이 롤백보다 빠릅니다.

9) 릴리스의 일부로 관찰 가능성

추적: 게이트웨이에서 DB/큐까지의 엔드 투 엔드 'trace _ id'; 이전/새 버전의 비교.
메트릭: p50/p95/p99, 오류율, RPS, 채도, DLQ, 리트레이, Time-to-Wallet/Business KPI.
로그: 구조화 된 PII 마스킹, '요청 _ id' 상관 관계.
경고: SLO 예산, 통화 중 긴급 페이지는 자동 컨볼 루션을 릴리스합니다.

10) 공급망 보안

릴리스 태그에 대한 각 빌드, 스토리지 및 바인딩에 대한 SBOM.
이미지 서명 (cosign), 클러스터 검증 (정책 입학).
SLSA 증명: 입증 가능한 인공물 기원.
OPA/Conftest (Policy-as-Code): 기본적으로 인프라 PR의 거부.
비밀: KMS 전용, 단기 토큰, 파이프 라인 교체.

11) 제어 및 프로세스 변경

RFC → CRQ → CAB: 문서화 된 동작/계약 변경에 사전에 동의합니다.
릴리스 캘린더: 제품/지역/팀별로 보이는 창.
런북: 각 구성 요소-활성화/롤백/진단 절차.
사후/복고풍: 중요한 석방 후-분석 및 조치.

12) 준비 테스트 프로파일

API/Events-Blocks와 호환되지 않는 변경 사항.
통합/e2e: 엔드 투 엔드 시나리오 "예금", "KYC", "인출".

연기 부하: 대표 피크; 우리는 자원 한계를 모니터링

혼돈 시나리오: 공급자 단절, 대기 시간 증가, 네트워크 플래핑.
합성 모니터링: 일정에 따른 "시험" 거래.

13) 릴리스 대상의 메이크 파일 예 (스 니펫)

makefile release: verify build test stage approve prod post verify:
@make lint test:unit sbom sast sca build:
docker build -t $(IMG).
cosign sign $(IMG)
test:
@make test:contract test:integration deploy:preview test:e2e stage:
kubectl apply -k deploy/staging approve:
@echo "Waiting for QA/CAB approval..."
prod:
make release:canary TRAFFIC="5 25 50 100"
post:
@make verify:slo notify changelog

14) 역할과 책임

Dev/Team: 코드 품질, 테스트, 마이그레이션, 런북.
QA: UAT/회귀 시나리오, 게이트의 품질 관리.
SRE/플랫폼: 파이프 라인 신뢰성, 관찰 성, 정책.
릴리스 관리자: 캘린더, 창, CAB, 최종 솔루션.
보안: SAST/DAST/SCA, 공급망, 비밀 정책.

15) 릴리스 성숙도 모델

1. 기본-수동 점검, 드문 릴리스, 롤백이 어렵습니다.
2. 고급-표준화 된 CI/CD, 등고선 준비, 카나리아/청록색, 빈번한 릴리스.
3. 전문가-세입자/지역별 점진적 배송, 플래그 우선, 코드 정책, SLO 자동 업로드, 전체 추적 성 및 SLSA가 특징입니다.

16) 구현 로드맵

M0-M1 (MVP): 파이프 라인 템플릿, 빌드 + 사인 + SBOM, 준비 배치, 기본 테스트 및 게이트.
M2-M3: 카나리아/청록색, PR 당 미리보기, 계약 테스트, DAST, 합성 검사.
M4-M6: 기능 플래그 플랫폼, 섀도우 트래픽, 코드 정책, 자동 롤백, 릴리스 캘린더 + CAB 워크 플로우.
M6 +: 지역별 링 배포, SLSA 인증 및 엄격한 입학, 런북의 전체 자동화.

17) 사전 릴리스 점검표

• 이미지 서명, SBOM로드 및 릴리스 바운드.
• 계약은 호환되며 테스트는 녹색이며 e2e는 준비에 전달됩니다.
• 마이그레이션 점검 (드라이 런), 백업 준비, 롤백 계획 설명.
• 대시 보드/알림이 업데이트되었으며 SLO 게이트가 활성화되었습니다.
• Runbook과 Changelog가 출판하고 릴리스 창이 동의했습니다.
• 기능 플래그는 점진적인 활성화를 위해 구성됩니다.
• 동결 제한이 충족되고 통화가 준비되었습니다.

간단한 결론

잘 설계된 스테이징 파이프 라인은 균일 한 템플릿, 투명한 품질의 게이트, 안전한 공급망, 점진적인 롤링 및 관찰 가능성으로 인해 위험을 줄이고 생산 변경 시간을 줄이면서 품질 및 비즈니스 지표에 대한 제어를 유지하면서 관리 가능한 루틴으로 전환합니다.