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