프로젝트 하나의 배포 스크립트를 다른 프로젝트에 가져다 썼는데 환경 변수 이름이 달라서 동작하지 않았다. 옮길 때마다 이름을 고치고 있었다.
Table of contents
Open Table of contents
대응표에서 드러난 차이
세 프로젝트의 변수를 뜻 기준으로 나란히 놓고 대응표를 만들었다. DB_HOST와 DB_USER와 DB_PASSWORD와 APP_ENV와 LOG_LEVEL 다섯 항목이 전부 다른 이름을 쓰고 있었다.
APP_ENV는 이름만이 아니라 값도 달랐다. 한 곳은 production까지 세 단계를 쓰고 다른 곳은 두 단계이며 또 다른 곳은 prod 축약형을 썼다.
조치 — 이름을 맞추는 이행
새 이름을 하나로 정한 뒤 두 가지 방법이 있었는데 옛 이름을 한 번에 없애는 것과 겹치는 기간을 두는 것이다. 뒤쪽을 골랐다. 이유는 한 번에 바꾸면 어느 배포에서 무엇이 빠졌는지 모른 채 깨져서다. 대신 옛 이름 분기가 코드에 한동안 남는 것을 감수했다. 새 이름을 먼저 읽고 없으면 옛 이름들을 차례로 읽게 하되 옛 이름을 쓰면 WARNING 로그를 남기게 했다.
경고가 안 나올 때까지 두고 그 뒤에 옛 이름 분기를 뺐다. 겹치는 기간을 두고 WARNING으로 잔여를 셌다.
주의 — 값의 정규화와 실패 지점
값도 여러 형태를 받아 하나로 맞추게 했다. 모르는 값이 오면 기본값으로 넘어가지 않고 시작할 때 exit 1로 죽게 했다.
조용히 기본값으로 가면 운영에서 개발 설정이 도는 사고가 난다. 필수 변수가 다 있는지도 시작 시점에 확인하게 했는데 전에는 첫 데이터베이스 조회에서 죽어서 그때는 원인이 안 보였다. 실패를 시작 시점으로 당기면 무엇이 없는지를 이름으로 말해 줄 수 있다.
설정 — 예시 파일과 스크립트 공유
세 프로젝트의 .env.example도 이름을 맞추고 필수와 선택을 나눠 적었다. 기본값이 있는 것은 그 값까지 적어서 새로 들어온 사람이 무엇을 채워야 하는지 바로 알게 했다.
이름을 맞추고 나니 스크립트가 어느 프로젝트에서든 그대로 돌았고 옮길 때 고칠 것이 없어졌다. 이름을 맞추는 것이 스크립트를 공유하는 조건이었다.
판단 기준 — 비밀 값의 위치
이름을 맞추고 나니 값을 어디에 두는지도 제각각인 것이 보였다. .env 파일과 컨테이너 environment와 SSM Parameter Store로 셋이 갈려 있었다.
Parameter Store가 가장 나았는데 값이 파일로 안 남고 접근 기록이 남기 때문이다. 운영과 시험은 그쪽으로 맞추고 개발은 .env를 그대로 뒀는데 개발에서까지 관리 서비스를 거치면 시작이 번거로워지기 때문이다. 환경에 따라 두는 곳을 달리하되 코드는 같게 두고 어디서 읽을지는 시작할 때 정해지게 했다.
정리
- 같은 뜻의 값이 프로젝트마다 다른 이름이면 옮길 때 깨진다
- 대응표를 만들고 이름을 하나로 맞춘다
- 옛 이름을 바로 없애지 말고 둘 다 읽되
WARNING을 남긴다 - 이름만이 아니라 값도 맞추고 모르는 값이면 시작할 때 죽게 한다
- 필요한 것이 다 있는지 시작할 때 확인한다
- 실패를 시작 시점으로 당기면 원인을 이름으로 말할 수 있다
.env.example에서 필수와 선택을 나눈다- 이름을 맞추는 것이 스크립트를 공유하는 조건이다