운영 및 → 관리 릴리스 및 업데이트주기
릴리스 및 업데이트주기
1) 목적
릴리스주기는 품질, 속도 및 투명성을 보장하는 방식으로 변경 사항이 사용자에게 언제 어떻게 전달되는지를 설정합니다. 잘 설계된주기:- 불확실성과 조정 비용을 줄입니다
- 사고 및 롤백의 위험을 줄입니다
- 기술을 비즈니스 이벤트 (마케팅, 스포츠, Fin.보고) 와 동기화
- CFR (실패율 변경) 성장없이 명령의 처리량을 향상시킵니다.
2) 출시 모델: 선택할 모델
1. 출시 열차-고정 슬롯 (예: 화요일/목 10:00 EET)
다중 팀 모놀리스 및 "무거운" 도메인 변경에 적합합니다.
2. 지속적인 배달 (요청시) - 양질의 게이트를 통과 한 모든 합병은 음식에 갈 수 있습니다.
마이크로 서비스 및 피처 플래그 문화에 적합합니다.
3. 하이브리드-열차의 제품 전선, "주문형" 백엔드 서비스.
선택 기준: 테스트/관찰 성숙도, 외부 파트너에 대한 의존성 (PSP/KYC), 규정 준수 요구 사항, 조직 규모.
3) 릴리스 캘린더 및 창
단일 캘린더 (회사 전체): 릴리스 슬롯, 데이터베이스 마이그레이션, 마케팅 캠페인, 주요 스포츠 이벤트, 보고 기간.
동결 기간: 핫픽스 P1 만 허용되는 명확하게 정의 된 창 (예: 챔피언스 리그 결승, 검은 금요일, 세금보고).
지역 파도: 먼저 "따뜻한" 시장/교통량이 적은 다음-기본; 현지 TZ의 야간 창문.
교차 정책: 하나의 중요한 경로 (지불, KYC, 승인) 에 따른 동시 변경 금지.
4) 분기 및 버전 지정
트렁크 기반 + 수명이 짧은 지점 (지점 3-5 일).
출시 지점-열차/긴 검증을위한 것입니다. '메인' 에서 하드 백 병합.
SemVer: 'MAJOR. 미노르. 라이브러리/SDK 용 PATCH '; 아티팩트 및 환경 태그.
계약: 백/포워드 호환성을 갖는 체계 (Avro/Proto); 이주-2 단계.
5) 품질 채널 (게이트)
1. 정적 + SAST/DAST + 라이터
2. 단위/계약/구성 요소 테스트
3. 연기 E2E/성능 (무대)
4. 보안/준수 검사
5. 출시 후보 → 서명, SBOM, 아티팩트
6. 자동 가드 레일을 사용한 프로그레시브 롤아웃 (§ 7 참조)
코드 및 정책 (Policy-as-Code) 의 모든 게이트는 릴리스 아티팩트입니다.
6) 환경 및 프로모션
데이터의 경우 Dev → Int → Stage → Prod: Sandbox/Data-Stage.
GitOps 프로모션, 불변의 이미지, "수동" 편집 금지
구조화: 구성 요소 (감사) 를 통한 지역, 제한, 제공자.
7) 롤링 전략
카나리아: 1% → 5% → 25% → 100% (지역당 и독점).
Blue-Green: 병렬 환경 + 원자 전환.
기능 플래그: 기능 스위치/킬 스위치; 그림자 그림자.
단계별 롤아웃 모바일/웹: 클라이언트 버전/배달 채널 (Store/OTA).
Gardrails (자동 정지): p95 대기 시간> 25%, 오류%> 2%, 승인/예금 감소, 청구서 증가, 1 시간 동안 연소 속도 SLO> 임계 값.
8) 비즈니스 및 파트너와의 조정
마케팅/이벤트: 48 시간 이상의 마진을 가진 캠페인을위한 기능 릴리스.
파트너 (PSP/KYC/게임 제공 업체): SDK 인증/업데이트 용 슬롯, 마이그레이션 기간의 이중 엔드 포인트.
지원: UX 변경, 상태 페이지, 에스컬레이션 채널에 대한 매크로/FAQ.
9) 데이터 및 스키마 업데이트
먼저 첨가하십시오: 먼저 추가 한 다음 마지막에 읽기/쓰기를 전환하십시오-오래된 것을 제거하십시오.
지수 및 대규모 마이그레이션-야간 창문, 배치, 체크 포인트 및 진행 상황.
창 및 메트릭 사전 버전 설정: 프로덕션 창과 별도로 릴리스와 동기식으로 업데이트되는 BI 마이그레이션.
10) 커뮤니케이션 및 인공물
릴리스 노트 (왜/왜/위험/롤백), 서비스 별 ChangeLog.
캘린더는 이해 관계자, 광고 템플릿 (전/도중/후에) 에 초대합니다.
열차/주요 출시 기간 동안의 전쟁 실 채널, 업데이트 빈도: P1-15-20 분마다.
11) 성능 지표
DORA: 배치 빈도, 리드 타임, 변경 실패율, MTTR.
변경 유형별 백 아웃 속도.
릴리스 전/후 SLO 준수%.
릴리스 부채: "매달린" 플래그, 불완전한 마이그레이션, 오래된 의존성.
비즈니스 영향: 전환, KYC TTV, PSP 성공, GGR/NGR 드리프트 창으로 드리프트.
12) 반 패턴
빅뱅: 깃발/카나리아가없는 "한 번에".
동결 예외없이 최대 트래픽/이벤트에서 릴리스하십
자동 가드 레일 없음: "눈으로" 수동 모니터링.
오래 지속 된 지점: 고통스러운 합병과 숨겨진 회귀.
판매의 수동 단계: 감사 및 예측 가능성 없음.
TTL 및 소유자가없는 깃발: "영원한" 가지.
13) 점검표
출시 전
- RFC/티켓, 위험 및 폭발 반경 평가
- CI/CD 게이트 통과, 아티팩트 서명
- 롤링 플랜 + 정지 기준 + 백 아웃 준비
- 캘린더, 동결 및 파트너와의 조정
- 대시 보드/알림 버전, 전쟁 실 생성
출시 당시
- 카나리아 단계와 자동 정지가 활성화되었습니다
- p95/오류% 메트릭, 모니터의 비즈니스 신호 (지정, KYC, PSP)
- 예정된 통신, 상태 페이지 새로 고침
출시 후
- 릴리스 노트 및 ChangeLog 게시
- 제거 된 깃발/임시 예외 (TTL)
- 편차가있는 경우 사후 사후 5 영업일
- 업데이트 된 플레이 북 및 문서
14) 미니 템플릿
릴리스 슬롯 템플릿 (기차):- 날짜/시간: 화요일 오전 10시 ~ 오후 12시 EET
- 선거구: EU (10% → 50% → 100%) 다음 LATAM (10% → 100%)
- 정지 기준: 오류%> 2% 10 분, p95> + 25% 10 분, PSP 성공 <97%
- 백아웃: 트래픽을 이전 버전 + 플래그 롤백으로 전환
- 연락처: @ RelEng, @ SRE-on-call, @ Support
- 새로운 것/왜
- 사용자 및 파트너에게 미치는 영향
- 위험 및 알려진 제한
- 롤링 플랜/중지 기준/백 아웃
- 모니터링 메트릭
- 연락처 및 지원 채널
15) 이웃 분야와의 통합
변경 관리: 분류 표준/정상/비상, CAB, 감사.
사고의 결과 감소: 기성품 기능 플래그, 할당량, 흘림.
구성 감사: Git, 드리프트 감지 및 응용 프로그램 로그를 통한 모든 프로모션.
실행 정책: 강압과 함께 코드와 같은 제한/타임 아웃/배상.
16) 결론
릴리스주기는 속도와 신뢰성 사이의 제어 된 리듬입니다. 조정이 필요한 고정 슬롯; 자동화 성숙도가있는 "주문형". 하나의 달력, 깃발 및 카나리아 롤, 자동 가드 레일 및 투명한 통신. 따라서 릴리스는 예측 가능하고 안전하며 경제적입니다.