배포 롤백 전략: 안전하게 되돌리는 자동화 설계
배포는 새 기능을 세상에 내보내는 순간이지만, 동시에 장애가 가장 많이 발생하는 순간이기도 합니다. 아무리 테스트를 촘촘히 짜도 프로덕션 트래픽과 실데이터 앞에서는 예상치 못한 문제가 튀어나옵니다.…
배포는 새 기능을 세상에 내보내는 순간이지만, 동시에 장애가 가장 많이 발생하는 순간이기도 합니다. 아무리 테스트를 촘촘히 짜도 프로덕션 트래픽과 실데이터 앞에서는 예상치 못한 문제가 튀어나옵니다.…
배포(deploy)와 릴리스(release)를 같은 것으로 취급하면, 코드를 프로덕션에 올리는 순간이 곧 사용자에게 기능이 노출되는 순간이 됩니다. 이 결합은 릴리스 타이밍을 배포 파이프라인에 묶어…
CI 파이프라인에서 가장 자주 손보게 되는 곳이 컨테이너 이미지 빌드입니다. 매번 몇 분씩 걸리는 docker build 는 개발 피드백 루프를 갉아먹고, CI 청구서도 불립니다. 다행히 Docke…
GitHub Actions를 쓰다 보면 두 갈림길을 만납니다. GitHub이 제공하는 호스티드 러너를 계속 쓸 것인가, 아니면 셀프호스티드 러너 를 직접 운영할 것인가. 빌드가 느려서, 요금이 부담…
모노레포가 커질수록 CI는 “매번 전부 빌드하고 전부 테스트하는” 관성 때문에 느려집니다. 패키지가 30개인데 하나만 고쳐도 30개를 전부 도는 파이프라인은 개발자 대기 시간을 잡아먹고 러너 비용을…
같은 커밋을 아무것도 안 바꾸고 다시 돌렸는데 이번엔 초록불이 뜬다. 어제까지 멀쩡하던 테스트가 오늘 아침 PR에서 빨간불을 내고, “재시도(Re-run)” 버튼을 한 번 누르면 통과한다. 팀 채널…
CI/CD 파이프라인이 성숙해질수록 반드시 마주치는 문제가 시크릿 관리입니다. DB 비밀번호, API 키, TLS 인증서, 클라우드 자격 증명 — 이런 값들을 어떻게 저장하고, 어떻게 배포 시점에 …
기능 브랜치를 만들고 며칠, 길게는 몇 주씩 작업하다 메인 브랜치에 합치려는 순간, 지옥이 시작된다. 그 사이 다른 사람들이 올린 수십 개의 커밋과 충돌하고, 충돌을 해결하고 나면 테스트가 깨지고,…
GitLab CI 파이프라인을 처음 구성할 때는 잘 동작하다가, 프로젝트가 커지고 잡(job)이 늘어나면 어느 순간 빌드 시간이 10분을 넘어가기 시작한다. 원인을 들여다보면 대부분 매 잡마다 의존…
개발팀이 빠르게 움직이려면 코드를 푸시한 후 “이 변경이 시스템을 망가뜨리지 않는다”는 확신을 최대한 빨리 얻어야 합니다. 그 확신을 주는 것이 CI 테스트이고, 그 확신을 얻는 데 걸리는 시간이 …
운영 중인 서비스를 중단 없이 새 버전으로 바꾸는 일은 쉬워 보이지만, 실제로는 수백만 원짜리 장애를 유발하는 가장 흔한 원인 중 하나입니다. 블루-그린, 카나리, 롤링 업데이트—세 전략은 각각 뚜…
GitHub Actions를 도입하고 얼마 지나지 않아 많은 팀이 같은 벽에 부딪힙니다. PR을 올릴 때마다 20~30분씩 기다리는 CI 실행 시간. 코드 몇 줄 고쳤을 뿐인데 의존성 수천 개를 처…
팀이 커지고 코드베이스가 복잡해질수록 가장 먼저 고통받는 것은 CI/CD 파이프라인 입니다. 처음에는 5분이던 빌드가 어느 순간 40분을 넘기고, 개발자들은 PR 하나를 머지하기 위해 점심시간을 통…