코드 업데이트 배포
기존에 배포된 앱에 새 코드를 적용하려면databricks apps deploy 명령을 다시 실행합니다.
| 상황 | 동작 | 비고 |
|---|---|---|
| 코드만 변경 | 새 컨테이너 빌드 후 교체 | 기존 설정 유지 |
requirements.txt 변경 | 의존성 재설치 후 배포 | 캐시 미스 시 시간 증가 |
app.yaml 변경 | 설정 반영 후 재배포 | 리소스·환경변수 포함 |
팁 배포 후 상태를 확인하려면databricks apps get my-app명령을 사용하세요.state필드가RUNNING이면 정상 배포된 것입니다.
설정 변경
app.yaml 수정 후 재배포
app.yaml의 설정을 변경한 뒤 databricks apps deploy를 실행하면 변경사항이 자동 반영됩니다.
환경변수 변경
| 방법 | 명령 / 위치 | 반영 시점 |
|---|---|---|
app.yaml env 섹션 수정 | databricks apps deploy | 재배포 시 |
| UI에서 직접 변경 | 워크스페이스 → Apps → 앱 선택 → Settings | 앱 재시작 시 |
리소스 바인딩 변경
SQL Warehouse, Model Serving Endpoint, Secret Scope 등의 리소스 바인딩을 변경할 때도app.yaml의 resources 섹션을 수정합니다.
롤백
문제가 발생하면 이전 버전으로 빠르게 되돌려야 합니다.Git 기반 롤백 (권장)
코드를 Git으로 관리하고 있다면 가장 안전하고 빠른 롤백 방법입니다.수동 롤백
Git을 사용하지 않는 경우, 이전에 동작하던 코드를 직접 배포합니다.| 롤백 방법 | 장점 | 단점 |
|---|---|---|
| Git checkout + deploy | 정확한 버전 추적, 감사 이력 | Git 사용 필수 |
| 수동 코드 교체 | Git 없이 가능 | 버전 추적 어려움, 실수 가능성 |
| DABs 번들 재배포 | CI/CD 파이프라인 연동 | 초기 설정 필요 |
주의 Databricks Apps는 현재 자체 버전 관리나 원클릭 롤백 기능을 제공하지 않습니다. 반드시 Git으로 코드를 관리하여 안정적인 롤백이 가능하도록 하세요.
무중단 업데이트 전략
블루-그린 배포 패턴
프로덕션 앱의 다운타임을 최소화하려면, 별도 앱으로 먼저 테스트한 뒤 전환하는 블루-그린 방식을 활용합니다.| 단계 | 앱 이름 | 상태 | 트래픽 |
|---|---|---|---|
| 배포 전 | my-app (v1) | RUNNING | 프로덕션 |
| 테스트 중 | my-app-staging (v2) | RUNNING | 내부 테스트만 |
| 전환 후 | my-app (v2) | RUNNING | 프로덕션 |
팁 스테이징 앱은 프로덕션과 동일한 리소스(SQL Warehouse, Serving Endpoint)를 바인딩하되, 별도의 테스트 데이터를 사용하는 것이 안전합니다. Service Principal을 분리하면 권한 격리도 가능합니다.
버전 관리 모범 사례
Git + DABs 활용
Databricks Asset Bundles (DABs)를 사용하면 앱 코드와 인프라 설정을 하나의 번들로 관리할 수 있습니다.CI/CD 파이프라인 연동
GitHub Actions 등의 CI/CD와 연동하면 코드 변경 시 자동으로 배포할 수 있습니다.버전 관리 체크리스트
| 항목 | 권장 사항 |
|---|---|
| 코드 관리 | Git 필수, 태그로 릴리스 버전 표시 |
| 의존성 고정 | requirements.txt에 버전 pinning (pandas==2.1.0) |
| 설정 분리 | app.yaml은 환경별로 분리 (dev/prod) |
| 시크릿 관리 | 하드코딩 금지, Secret Scope 또는 환경변수 활용 |
| 배포 자동화 | DABs + CI/CD로 수동 배포 최소화 |
| 테스트 | 배포 전 스테이징 환경에서 검증 |
| 모니터링 | 배포 후 databricks apps get으로 상태 확인 |