프리뷰 환경 자동 구축: PR마다 임시 배포 만들기
기능 브랜치에서 UI를 고쳤는데 리뷰어가 그 변화를 확인하려고 브랜치를 체크아웃해 로컬에 띄워봐야 한다면 리뷰의 마찰이 크게 늘어난다. 코드 diff만 보고 “버튼 정렬이 실제로 어떻게 보이는지”, “이…
기능 브랜치에서 UI를 고쳤는데 리뷰어가 그 변화를 확인하려고 브랜치를 체크아웃해 로컬에 띄워봐야 한다면 리뷰의 마찰이 크게 늘어난다. 코드 diff만 보고 “버튼 정렬이 실제로 어떻게 보이는지”, “이…
쿠버네티스에 애플리케이션을 배포하다 보면 매니페스트가 순식간에 수십 개로 불어난다. Deployment, Service, ConfigMap, Ingress, HPA가 환경마다 조금씩 다르고, 이미지 태그 하나 바꾸려고 여러 파일을 손대다 보면 “지금…
대부분의 CI 도구는 쿠버네티스 바깥에 살면서 클러스터를 원격으로 조종한다. Jenkins 마스터, GitLab 러너, GitHub Actions 워커가 kubectl apply나 헬름 명령을 던지는 구조다. 익숙하지만, 파이프라인의 상태·권한·확장이 전부…
애플리케이션 하나를 빌드하면 직접 작성한 코드는 전체의 5~10%에 불과하고 나머지는 오픈소스 의존성이다. 그 의존성은 또 다른 의존성을 끌어오고, 이 전이(transitive) 관계는 수백 단계까지 뻗어나간다. 이 사슬…
프로젝트가 오래될수록 의존성은 조용히 낡아간다. 보안 취약점 알림을 받고 나서야 여러 버전을 한꺼번에 올리려다 빌드가 무너지는 경험은 대부분의 팀이 겪는다. 이 “한 번에 몰아서 업데이트”의 고통을…
초록불을 유지하던 CI가 어느 날부터 같은 커밋을 두 번 돌리면 한 번은 통과하고 한 번은 실패하기 시작하면, 팀은 조용히 위험한 습관을 들인다. 바로 “일단 재시도(retry) 버튼을…
오래 굴러온 Jenkins 파이프라인은 대개 하나의 거대한 생명체처럼 자라 있다. 수십 개의 Jenkinsfile, 손으로 설치한 플러그인 더미, 특정 노드에만 존재하는 도구 버전, 아무도 전체를 이해하지 못하는…
라이브러리나 CLI 도구를 만들다 보면 “이게 Python 3.9에서도 돌아가나?”, “Windows에서는 경로 처리가 깨지지 않나?” 같은 질문이 계속 쌓인다. 이걸 손으로 하나씩 확인하는 건 현실적이지 않고, 워크플로…
쿠버네티스 배포는 대개 kubectl apply나 CI 파이프라인에서 매니페스트를 클러스터로 직접 밀어넣는 푸시(push) 방식에서 출발한다. 처음엔 잘 돌아가지만 서비스와 환경이 늘면 문제가 드러난다. 클러스터에 실제로 무엇이 떠…
배포는 새 기능을 세상에 내보내는 순간이지만, 동시에 장애가 가장 많이 발생하는 순간이기도 합니다. 아무리 테스트를 촘촘히 짜도 프로덕션 트래픽과 실데이터 앞에서는 예상치 못한 문제가 튀어나옵니다. 이때…