코드 관리를 위해 git을 사용하는 경우 개발 브랜치 dev와 온라인 브랜치 pro가 있습니다.
개발 중에는 모든 사람이 dev 브랜치에서 자신의 브랜치를 가져와 개발하고 완료 후 dev 브랜치에 병합합니다.
온라인 환경이 업데이트되면 pro 브랜치에서 최신 코드를 가져온 후 서비스가 다시 시작됩니다.
여기서 문제가 발생합니다. dev 브랜치와 pro 브랜치에는 구성 파일, 설정 등 여러 파일이 있는 경우가 많습니다. 이 상황에서 적절한 접근 방식은 무엇입니까?
git에 설정 파일이 포함되어 있지 않은 경우, 구성 파일을 업데이트해야 하는 경우 온라인 환경에서 수동으로 코드를 수정해야 합니다.
어떻게 하셨나요? 자동화된 배포 및 롤백을 달성하기 위해 git을 결합하시겠습니까?
감사합니다
高洛峰2017-05-02 09:27:01
프로덕션 환경과 비프로덕션 환경(예: 개발 환경, 테스트 환경 등)의 차이는 구성 외에도 일부 종속 리소스도 서로 다를 수 있습니다.
여기서 제가 사용하는 일반적인 방법은 프로덕션 환경과 기타 환경의 모든 구성을 해당 구성 파일(또는 여러 파일 config/dev.json, config/pro.json...)에 작성하는 것입니다. 구성 프로세서는 로컬 환경(git의 범위에 포함되며 초기화 모듈일 수 있음)이 무엇인지 읽고 구성 파일에서 해당 환경의 구성을 읽습니다. 하나의 구성 파일을 사용하면 다음과 유사합니다.
으아아아구성 프로세서는 현재 환경이 무엇인지 어떻게 알 수 있습니까? 여기에 环境标识가 있어야 합니다. 예를 들어 프로덕션 환경은 고정 IP에 배포됩니다. 단일 서버 단일 애플리케이션에 적합) 구성 파일의 프로덕션 환경 구성은 이 IP 아래에 기록됩니다. 구성 프로세서는 현재 실행 중인 환경의 IP를 얻은 후 구성 파일에 지정된 IP 모듈의 구성을 읽습니다. 🎜> 또 다른 방법은
을 사용하는 것입니다. 예를 들어 애플리케이션이 실행되는 모든 환경에는 /data/tag 텍스트 파일이 있습니다(프로젝트 디렉터리에 있을 수도 있지만 .gitignore에 포함됨). 파일은 git의 범위 내에 있지 않습니다. 标识文件 또는 pro로 작성된 한 줄만 있으므로 구성 프로세서는 이 파일을 읽어서 얻을 구성 파일의 부분을 알 수 있습니다. 가장 일반적인 방법은 dev과 같은 환경 변수를 사용한 다음 이 변수를 먼저 읽는 것입니다. 해당 환경 구성을 다시 읽어보세요.
export APP_ENV=production구성 서버
가 있어야 합니다. 각 서버의 애플리케이션 구성을 업데이트합니다. 이 구성 서버에서는 어떤 서버가 어떤 구성을 사용하는지 독립적으로 구성할 수 있습니다(일반적으로 요청자의 IP로 구성됨). 이런 방식으로 애플리케이션은 완전히 상태를 유지하지 않고
구성 파일이 전혀 필요하지 않으며
구성을 세밀하게 제어할 수 있습니다(예: 특정 서버의 요청 흐름을 늘리고 싶다), 그레이 스케일 릴리스 구현(일부 서버에 새 코드 배포)을 구현하는 것 외에도 현재 대부분의 인터넷 회사에서 채택하는 방법이 아닐까 생각합니다.
