Big Tech가 Production에 코드를 전송하는 방법

How Big Tech Ships Code to Production

 

크게 단계를 위 내용처럼 나누었다.

 

Plan(계획)

P1. 사용자 피드백, 요구사항 수집( product 팀 )

P2. 수집된 요건을 더 작은 작업 항목(work items)이나 사용자 이야기로 생성( product & engineering 팀 )

 

Development

D1. P2 단계에서 생성된 항목에 대해 sprint 미팅에서(1~2주기간) 개발자가 pick up
       (좀더 규모가 큰 프로젝트에서는 작업이 여러번의 스프린트를 통해 수행될수도 있음. 엔지니어링 관리자 또는 tech 리더가 팀 역량의 균형을 맞추기 위해 스프린트 전반에 걸쳐 항목의 우선순위를 정하고 순서 결정)

D2. Sprint가 계획되면, 개발 착수. 이때 규모가 있다면, 높은 수준의 아키텍처를 적절하게 하고 기술적 접근을 미리하기 위해 RFC(Request for Comments) 또는 설계 문서 작성. 아래 설계 문서에 포함되는 대한 내용

 

요약
동기부여
상세 설계
대안 고려
의견의 자유로운 표명을 구하는 문제(안건)

 

 

 

 

 

 

 

 

 

 

D3. 기존 프로그램 / Data에 영향을 주지않는 개발 수행.

개발 과정 : Commit - PR(Pull Request) 요청 - Code Reviews - Deploy(배포) - Merge PR

 

Database Scheme 변경시 데이터의 충돌을 사전에 고려한 설계가 필수적

 

Build & Package

B1. 자동화 도구(Github Actions, Jenkins, Bamboo)를 활용한 자동 빌드 / 배포
     개발, tesh, staging 환경은 중요. 필수적.

 

Test

T1. 기능적으로 문제가 없는지 검증, 회귀 테스트 수행( QA 엔지니어 )
     QA 없이 개발자가 자체적으로 수행하는게 가능한 곳도 있겠지만 전체는 아니다.

T2. 앞선 단계가 모두 완료되면 UAT(user acceptance testing) 수행( 개발자, Product, QA ) 

 

Release

R1. 카나리 배포, Feature toggle, A/B 테스트 등의 다양한 방법으로 risk를 줄이며 배포

R2. 메트릭, 로그, 트래픽 모니터링을 통해 모니터링, 알람, 안전성 향상 수행( SRE 엔지니어 )  

 

 

출처bytebytego/ https://www.youtube.com/watch?v=xSPA2yBgDgA