<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>롤백 on 얼쑤 · Team Edo</title><link>https://team-edo.github.io/tags/%EB%A1%A4%EB%B0%B1/</link><description>Recent content in 롤백 on 얼쑤 · Team Edo</description><generator>Hugo</generator><language>ko-kr</language><lastBuildDate>Fri, 06 Nov 2026 00:00:00 +0900</lastBuildDate><atom:link href="https://team-edo.github.io/tags/%EB%A1%A4%EB%B0%B1/index.xml" rel="self" type="application/rss+xml"/><item><title>Flyway 선실행과 배포 롤백</title><link>https://team-edo.github.io/posts/2026/11/flyway-deploy-rollback/</link><pubDate>Fri, 06 Nov 2026 00:00:00 +0900</pubDate><guid>https://team-edo.github.io/posts/2026/11/flyway-deploy-rollback/</guid><description>&lt;p>새 버전이 배포된 뒤 readiness는 &lt;code>UP&lt;/code>이었는데, 모범 음원 조회는 HTTP 500을 반환했습니다. 새 앱은 음원의 저장소 객체 키를 읽으려 했고, 운영 DB에는 그 컬럼이 아직 없었습니다. 실행 중인 앱을 그대로 두고 밀린 마이그레이션을 적용하자 같은 요청은 게시된 음원이 없을 때의 응답인 404로 바뀌었습니다. DB 연결이 정상이어도 새 쿼리에 필요한 컬럼이 준비됐는지는 별도로 확인해야 했습니다.&lt;/p>
&lt;p>당시 앱 배포는 자동이었고 Flyway 적용은 수동이었습니다. 앱 교체와 스키마 변경의 순서를 사람이 맞춰야 했습니다. 이 배포 흐름을 바꾸는 작업에 참여하면서, 새 앱이 필요한 스키마를 먼저 준비하고 이전 앱도 그 스키마에서 계속 동작할 수 있어야 한다는 두 가지 조건을 함께 다뤘습니다.&lt;/p></description></item></channel></rss>