일반적인 웹 앱과 파일 구성이 있다고 가정 해 보겠습니다. 프로젝트에서 작업하는 모든 개발자는 개발 상자에 대해 하나의 버전을 갖게되며 개발, 제품 및 단계 버전이 있습니다. 소스 제어에서 이것을 어떻게 처리합니까? 이 파일을 전혀 체크인하지 않거나 다른 이름으로 확인하거나 모두 멋진 일을하십니까?
답변
내가 과거에 한 일은 소스 제어에 체크인되는 기본 구성 파일을 갖는 것입니다. 그런 다음 각 개발자는 소스 제어에서 제외되는 자체 재정의 구성 파일을 갖습니다. 앱은 먼저 기본값을로드 한 다음 재정의 파일이있는 경우이를로드하고 기본 파일보다 우선적으로 재정의의 모든 설정을 사용합니다.
일반적으로 재정의 파일이 작을수록 더 좋지만 매우 비표준 환경의 개발자를 위해 항상 더 많은 설정을 포함 할 수 있습니다.
답변
구성 은 코드이며 버전을 지정해야합니다. 구성 파일은 사용자 이름을 기반으로합니다. UNIX / Mac 및 Windows 모두에서 사용자의 로그인 이름에 액세스 할 수 있으며 이들이 프로젝트에 고유 한 한 괜찮습니다. 환경에서이를 재정의 할 수도 있지만 모든 버전을 제어 해야합니다 .
또한 빌드 및 플랫폼 문제를 진단하는 데 도움이되는 다른 사람의 구성을 검사 할 수 있습니다.
답변
해당 파일의 버전을 지정하지 마십시오. 템플릿을 버전 화합니다.
답변
우리 팀은 각 환경 (web.config.dev, web.config.test, web.config.prod)에 대해 별도의 구성 파일 버전을 유지합니다. 배포 스크립트는 올바른 버전을 복사하여 이름을 web.config로 바꿉니다. 이렇게하면 각 환경의 구성 파일에 대한 전체 버전 제어가 가능하고 쉽게 diff 등을 수행 할 수 있습니다.
답변
현재 다음과 같이 확장명이 추가 된 “템플릿”구성 파일이 있습니다.
web.config.rename
그러나 중요한 변경 사항이 변경된 경우이 방법에 문제가 있음을 알 수 있습니다.
답변
템플릿 접근 방식에 +1.
그러나이 질문에는 태그 Git이 있기 때문에 사용자 정의가 비공개 테스트 브랜치에 유지되는 분산 형 대안이 떠 오릅니다.
A---B---C---D--- <- mainline (public)
\ \
B'------D'--- <- testing (private)
이 체계에서 메인 라인에는 최소한의 조정이 필요한 일반 “템플릿”구성 파일이 포함되어 있습니다.
이제 개발자 / 테스터는 구성 파일을 마음대로 조정할 수 있으며 이러한 변경 사항은 비공개 테스트 분기 (예 : B ‘= B + 사용자 지정)에서 로컬로만 커밋 할 수 있습니다. 메인 라인이 발전 할 때마다 쉽게 테스트에 병합하여 D ‘(= D + B의 사용자 지정 병합 버전)와 같은 병합 커밋이 발생합니다.
이 체계는 “템플릿”구성 파일이 업데이트 될 때 실제로 빛을 발합니다. 양쪽의 변경 사항이 병합되고 호환되지 않는 경우 충돌 (또는 테스트 실패)이 발생할 가능성이 매우 높습니다!
답변
우리가 사용하는 솔루션은 단일 구성 파일 (web.config / app.config) 만 갖는 것이지만 모든 환경에 대한 설정이 포함 된 파일에 특수 섹션을 추가합니다.
이있는 LOCAL, DEV, 품질 보증, 생산 부분 우리의 config 파일 (들)에 해당 환경에 관련된 구성 키를 포함하는 각.
이 모든 것이 작동하도록 만드는 것은 모든 애플리케이션 (winforms 및 webforms)에서 참조되는 xxx.Environment 라는 어셈블리로 애플리케이션이 작동중인 환경을 알려줍니다.
xxx.Environment 어셈블리 는 주어진 시스템 의 machine.config 에서 DEV, QA 등에 있음을 알려주 는 정보의 한 줄을 읽습니다 .이 항목은 모든 워크 스테이션과 서버에 있습니다.
도움이 되었기를 바랍니다.