https://team-edo.github.io/tags/%EB%B0%B0%ED%8F%AC/Recent content in 배포 on 얼쑤 · Team EdoHugoko-krFri, 06 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/flyway-deploy-rollback/Fri, 06 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/flyway-deploy-rollback/<p>새 버전이 배포된 뒤 readiness는 <code>UP</code>이었는데, 모범 음원 조회는 HTTP 500을 반환했습니다. 새 앱은 음원의 저장소 객체 키를 읽으려 했고, 운영 DB에는 그 컬럼이 아직 없었습니다. 실행 중인 앱을 그대로 두고 밀린 마이그레이션을 적용하자 같은 요청은 게시된 음원이 없을 때의 응답인 404로 바뀌었습니다. DB 연결이 정상이어도 새 쿼리에 필요한 컬럼이 준비됐는지는 별도로 확인해야 했습니다.</p> <p>당시 앱 배포는 자동이었고 Flyway 적용은 수동이었습니다. 앱 교체와 스키마 변경의 순서를 사람이 맞춰야 했습니다. 이 배포 흐름을 바꾸는 작업에 참여하면서, 새 앱이 필요한 스키마를 먼저 준비하고 이전 앱도 그 스키마에서 계속 동작할 수 있어야 한다는 두 가지 조건을 함께 다뤘습니다.</p>https://team-edo.github.io/posts/2026/11/split-manual-web-deployment/Fri, 06 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/split-manual-web-deployment/<p>얼쑤의 Jenkins는 개발 브랜치 변경을 감지하면 백엔드를 검사하고 배포했습니다. 뒤이어 웹 잡도 자동으로 예약되는 구조여서, 백엔드 변경을 운영에 올릴 때도 별도의 웹 빌드가 시작됐습니다. 웹 배포 시점을 따로 정할 수 있게 트리거를 나누되, 운영 웹이 어떤 소스에서 나왔는지는 계속 확인할 수 있어야 했습니다.</p> <h2 id="수동으로-실행해도-소스를-지정하게-했다">수동 배포에서 소스 SHA 지정</h2> <p>백엔드의 자동 배포는 두고, 웹은 트리거가 없는 전용 잡으로 옮겼습니다. 운영자는 성공한 백엔드 빌드에서 검증한 전체 커밋 SHA를 웹 잡에 입력합니다. 웹 잡은 체크아웃 결과가 입력과 같고 해당 SHA가 개발 브랜치 이력에 포함되는지 확인한 뒤 빌드를 시작합니다. 기존 웹 잡은 비활성화해 이력 조회용으로 남겼습니다.</p>https://team-edo.github.io/posts/2026/11/separate-terms-publication-from-effective-time/Mon, 02 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/separate-terms-publication-from-effective-time/<p>새 약관을 배포한 날 저녁, 웹의 <code>current</code> 주소는 새 문서를 보여줬습니다. 그런데 앱이 조회하는 약관 목록에 새 판이 들어간 건 자정 뒤였습니다. 문서 버전에 시행일을 적어 두었지만, 웹과 API가 버전을 고르는 방식은 서로 달랐습니다.</p> <h2 id="배포와-시행이-갈라진-시간">자정 뒤 전환된 약관 목록</h2> <p>11월 2일 19:27 KST에 새 판이 들어 있는 변경을 병합했고, 19:36 배포 확인에서 <code>current</code>가 시행일 11월 3일인 문서를 보여주는 것을 확인했습니다. 이미 11월 2일 판이 있어서 같은 날짜를 새 문서에 다시 쓸 수는 없었습니다. 병합부터 자정까지 약 4시간 반 동안 문서의 날짜와 현재라고 표시되는 시점이 어긋났습니다.</p>https://team-edo.github.io/posts/2026/10/analysis-service-network-boundary/Thu, 29 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/analysis-service-network-boundary/<p>얼쑤의 백엔드는 녹음 분석을 요청할 때 파일을 읽을 수 있는 서명 URL을 넘깁니다. 분석 서버는 그 주소에서 녹음을 내려받아 채점합니다. 이 서버를 운영에 추가할 때 외부에서 직접 호출할 수 있는 포트가 필요한지 먼저 살폈습니다. 앱은 이미 백엔드로 녹음을 올리고 결과를 조회하고 있어서, 분석 서버는 백엔드에서만 호출하면 됐습니다.</p> <h2 id="녹음-주소를-받는-api의-접근-범위">녹음 URL을 받는 API의 접근 범위</h2> <p>당시 분석 API는 호출자를 인증하거나 다운로드 목적지의 호스트를 제한하지 않았습니다. URL이 HTTP나 HTTPS로 시작하는지는 확인했지만, 사설 주소도 그 조건을 충족합니다. 외부 호출자가 이 API에 요청을 보낼 수 있다면 서버가 대신 내부 주소에 접속하게 할 수 있습니다. 응답 차이만으로도 어떤 주소에 연결이 됐는지 짐작할 여지가 생깁니다.</p>https://team-edo.github.io/posts/2026/10/separate-deployment-health-probes/Wed, 28 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/separate-deployment-health-probes/<p>얼쑤에서 새로 병합한 약관 조회 API를 운영에서 호출했더니 404가 돌아왔습니다. 기존 서비스는 계속 응답하고 있었지만, 실행 중인 JAR의 버전과 컨테이너가 시작한 시각을 확인하니 그 뒤의 변경은 배포되지 않은 상태였습니다. 처음 살펴본 Jenkins 실행 열 건은 연속으로 배포 검사에서 실패했습니다.</p> <p>Jenkins API에서 인증 때문에 실행 기록을 읽을 수 없어, 서버에서 빌드별 <code>build.xml</code>과 콘솔 로그를 읽었습니다. <code>build.xml</code>의 결과·시작 시각·커밋 SHA를 콘솔 로그의 마지막 실패 단계와 맞춰 보니, 서로 다른 커밋의 배포가 같은 검사에서 멈췄습니다.</p>https://team-edo.github.io/posts/2026/10/rerun-safe-deployment-backup/Wed, 28 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/rerun-safe-deployment-backup/<p>배포 도구를 교체할 때 현재 파일을 백업하고, 준비한 새 파일을 설치하는 명령을 이어서 실행했습니다. 같은 명령을 다시 실행했더니 <code>install</code>에서 후보 파일을 찾지 못했습니다. 실패 메시지는 마지막 단계에서 나왔지만, 그 전에 실행된 복사가 기존 백업을 이미 바꾼 뒤였습니다.</p> <p>첫 실행에서는 백업 파일에 이전 버전이 들어갔고 설치 경로에는 새 버전이 들어갔습니다. 두 번째 실행에서는 그 새 버전이 같은 이름의 백업 위에 복사됐습니다. 그 뒤에야 설치할 후보 파일이 없다는 오류가 났습니다. 이번에는 변경 전 도구가 저장소 이력에 있어 이전 내용을 찾을 수 있었습니다. 운영에서만 관리하는 파일이라면 동일한 복원 경로를 기대하기 어렵습니다. 실제로 도구를 이전 상태로 복구했거나, 수정한 절차로 설치를 다시 검증했다는 기록은 없습니다.</p>