Architecture Decision Record환경 변수 설정
목차:
요약
이슈
우리는 애플리케이션이 산출물/바이너리/소스를 넘어 설정 가능하기를 원하며, 하나의 빌드가 배포 환경에 따라 다르게 동작할 수 있어야 합니다.
이를 위해 환경 변수 설정을 사용하고자 합니다.
버전 관리가 가능한 파일을 사용하여 설정을 관리하고자 합니다.
무엇을 설정할 수 있는지와 관련 기본값을 아는 것 같은 일부 개발자 경험의 편의성을 제공하고자 합니다.
결정
.env 파일과 관련 기본값 파일 및 스키마 파일로 결정했습니다.
상태
결정됨. 새로운 기능이 나오면 열린 자세로 검토합니다.
세부 사항
가정
우리는 애플리케이션 코드와 환경 코드를 분리하는 것을 선호합니다. 앱은 개발 환경, 테스트 환경, 데모 환경, 운영 환경 등 서로 다른 환경에서 다르게 동작해야 한다고 가정합니다.
우리는 “12 factor app”이라는 업계 관행을, 그리고 그보다 더 관련 관행인 “15 factor app”을 선호합니다.
우리의 이전 프로젝트 중 다수는 .env 파일이나 유사한 .env 디렉터리라는 관례를 사용했습니다. 이를 버전 관리에서 제외하고 대신 다른 방법으로 배포하고, 버전을 매기고, 관리하는 것이 일반적인 관행입니다.
제약
우리는 비밀 정보를 소스 코드 관리(SCM) 버전 관리 시스템(VCS) 밖에 두고자 합니다.
우리는 인기 있는 소프트웨어 프레임워크 및 라이브러리와의 호환성을 목표로 합니다. 예를 들어 Node에는 환경 변수 설정을 읽는 “dotenv” 모듈이 있습니다.
입장
우리는 몇 가지 접근 방식을 검토했습니다:
config.js파일 같은 앱 안에 설정을 저장한다..env파일 같은 환경에 설정을 저장한다.라이선스 서버 같은 알려진 위치에서 설정을 가져온다.
논거
우리는 다음 이유로 .env 파일 접근 방식을 선택했습니다:
전문가들 사이에서도 인기가 있습니다.
우리 팀이 많은 프로젝트에서 여러 번 성공적으로 사용한
.env파일 패턴을 따릅니다.단순합니다. 특히, 라이선스 서버 접근 방식에 비해 감사 기능이 부족한 것 같은 우리가 인지하는 상당한 트레이드오프는 당분간 괜찮습니다.
영향
공개된 환경 변수 설정을 비밀 정보 관리와 분리하는 방법을 찾아야 합니다.
관련 항목
관련 결정
우리는 모든 애플리케이션이 이 접근 방식을 사용하기를 기대합니다.
바이너리나 소스 코드에 하드코딩하는 것 같은 덜 유능한 접근 방식을 사용하는 애플리케이션은 업그레이드할 계획입니다.
라이선스 서버 같은 더 유능한 접근 방식을 사용하는 애플리케이션은 그대로 유지합니다.
관련 요구사항
파일에 대한 훅, 테스트, 지속적 통합을 포함한 데브옵스 기능을 추가할 것입니다.
모든 개발자 팀원에게 이 결정에 대해 교육해야 합니다.
관련 산출물
배포하는 각 영역에는 자체 .env 파일과 관련 파일이 필요합니다.
관련 원칙
쉽게 되돌릴 수 있음.
메모
.env 파일 예시:
NAME=Alice Anderson
EMAIL=alice@example.com
.env.defaults 파일 예시:
NAME=Joe Doe
EMAIL=joe@example.com
키만 있는 .env.schema 파일 예시:
NAME
EMAIL