일반적인 웹 앱과 파일 구성이 있다고 가정 해 보겠습니다. 프로젝트에서 작업하는 모든 개발자는 개발 상자에 대해 하나의 버전을 갖게되며 개발, 제품 및 단계 버전이 있습니다. 소스 제어에서 이것을 어떻게 처리합니까? 이 파일을 전혀 체크인하지 않거나 다른 이름으로 확인하거나 모두 멋진 일을하십니까?
답변:
구성 은 코드이며 버전을 지정해야합니다. 구성 파일은 사용자 이름을 기반으로합니다. UNIX / Mac 및 Windows 모두에서 사용자의 로그인 이름에 액세스 할 수 있으며 이들이 프로젝트에 고유 한 한 괜찮습니다. 환경에서이를 재정의 할 수도 있지만 모든 버전을 제어 해야합니다 .
또한 빌드 및 플랫폼 문제를 진단하는 데 도움이되는 다른 사람의 구성을 검사 할 수 있습니다.
현재 다음과 같이 확장명이 추가 된 "템플릿"구성 파일이 있습니다.
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 등에 있음을 알려주 는 정보의 한 줄을 읽습니다 .이 항목은 모든 워크 스테이션과 서버에 있습니다.
도움이 되었기를 바랍니다.
나는 항상 web.config 파일과 동일한 폴더에 소스 제어의 모든 버전의 구성 파일을 보관했습니다.
예를 들면
web.config
web.qa.config
web.staging.config
web.production.config
web.config.production 또는 production.web.config와는 반대로이 명명 규칙을 선호합니다.
기본 구성 파일은 자체 시스템에서 로컬로 애플리케이션을 실행할 수 있도록 구성되어야합니다.
가장 중요한 것은 이러한 파일이 서식을 포함하여 모든 측면에서 거의 100 % 동일해야한다는 것입니다. 한 버전에서는 탭을 사용하고 들여 쓰기를 위해 다른 버전에서는 공백을 사용하면 안됩니다. 파일 간의 차이점을 정확히 확인하려면 파일에 대해 diff 도구를 실행할 수 있어야합니다. 파일 비교를 위해 WinMerge를 사용하는 것을 선호합니다.
빌드 프로세스에서 바이너리를 만들 때 해당 환경에 적합한 구성 파일로 web.config를 덮어 쓰는 작업이 있어야합니다. 파일이 압축 된 경우 해당 빌드에서 관련없는 파일을 삭제해야합니다.
나는 이전에 web.dev.config, web.prod.config 등과 같은 템플릿을 사용했지만 이제는 '파일 덮어 쓰기'기술을 선호합니다. web.config 파일에는 대부분의 설정이 포함되어 있지만 외부 파일에는 db 연결과 같은 환경 별 값이 포함되어 있습니다. Paul Wilson의 블로그 에 대한 좋은 설명입니다 .
새 값 / 속성을 추가 할 때 고통을 유발할 수있는 구성 파일 간의 중복 양을 줄입니다.
버전 제어에 체크인 된 템플릿 구성 파일을 사용하고 자동화 된 빌드의 단계를 사용하여 템플릿 파일의 특정 항목을 환경 별 설정으로 바꿉니다. 환경 별 설정은 버전 제어를받는 별도의 XML 파일에 저장됩니다.
우리는 자동화 된 빌드에서 MSBuild를 사용하고 있으므로 MSBuild 커뮤니티 작업 의 XmlUpdate 작업 을 사용하여 값을 업데이트합니다.
오랫동안 저는 bcwood가했던 일을 정확히 해왔습니다. web.dev.config, web.test.config, web.prod.config 등의 복사본을 소스 제어하에 보관 한 다음 빌드 / 배포 시스템이 다양한 환경에 배포 할 때 자동으로 이름을 바꿉니다. 파일 사이에 일정량의 중복이 발생하지만 (특히 모든 asp.net 항목에서) 일반적으로 잘 작동합니다. 또한 팀의 모든 구성원이 변경 사항을 적용 할 때 모든 파일 을 업데이트 해야 함을 기억해야 합니다.
그건 그렇고, 파일 연결이 끊어지지 않도록 끝에 ".config"를 확장자로 유지하는 것을 좋아합니다.
구성 파일의 로컬 개발자 버전에 관해서는 항상 사람들이 가능한 한 동일한 로컬 설정을 사용하여 자신의 버전을 가질 필요가 없도록 최선을 다합니다. 항상 모든 사람에게 작동하는 것은 아닙니다.이 경우 사람들은 일반적으로 필요에 따라 로컬로 교체하고 거기에서 이동합니다. 너무 아프거나 아무것도 아닙니다.
여기에 두 가지 문제가 있습니다.
먼저 소프트웨어와 함께 제공되는 구성 파일을 제어해야합니다.
개발자가 개발 환경에서 동일한 파일을 사용하는 경우 개발자가 원하지 않는 마스터 구성 파일 변경을 체크인하는 것은 쉽습니다.
반면에 설치 프로그램에 포함 된 별도의 구성 파일이있는 경우 새 설정을 추가하는 것을 잊거나 그 안의 주석이 계승의 주석과 동기화되지 않도록하는 것은 매우 쉽습니다. 구성 파일.
그런 다음 다른 개발자가 새 구성 설정을 추가 할 때 개발자가 구성 파일 사본을 최신 상태로 유지해야하는 문제가 있습니다. 그러나 데이터베이스 연결 문자열과 같은 일부 설정은 개발자마다 다릅니다.
질문 / 답변이 다루지 않는 세 번째 문제가 있습니다. 새 버전의 소프트웨어를 설치할 때 고객이 구성 파일에 적용한 변경 사항을 어떻게 병합합니까?
나는 아직 모든 경우에 잘 작동하는 좋은 솔루션을 보지 못했지만 문제를 많이 줄이는 부분 솔루션 (필요에 따라 다른 조합으로 결합 할 수 있음) 을 보았습니다 .
먼저 기본 구성 파일에있는 구성 항목의 수를 줄이십시오.
고객이 매핑을 변경하도록 할 필요가없는 경우 Fluent NHibernate (또는 기타)를 사용하여 구성을 코드로 이동하십시오.
의존성 주입 설정도 마찬가지입니다.
가능하면 구성 파일을 분할하십시오. 예를 들어 별도의 파일을 사용하여 Log4Net 로그를 구성하십시오.
여러 구성 파일 사이에 항목을 반복하지 마십시오. 예를 들어 동일한 시스템에 모두 4 개의 웹 응용 프로그램이 설치된 경우 각 응용 프로그램의 web.config 파일이 가리키는 전체 구성 파일이 있습니다.
(기본적으로 상대 경로를 사용하므로 web.config 파일을 변경해야하는 경우는 거의 없습니다.)
개발 구성 파일을 처리하여 배송 구성 파일을 가져옵니다.
빌드가 완료되면 구성 파일에 설정되는 Xml 주석에 기본값이 있습니다. 또는 설치 프로그램 생성 프로세스의 일부로 삭제 된 섹션이 있습니다.
데이터베이스 연결 문자열을 하나만 사용하는 대신 개발자 당 하나씩 사용하십시오.
예를 들어 런타임에 구성 파일에서 "database_ianr"(여기서 ianr은 내 사용자 이름 또는 컴퓨터 이름)를 먼저 찾고, 찾을 수없는 경우 "database"를 찾습니다.
두 번째 수준 "예 : -oracle 또는 -sqlserver"를 사용하면 개발자가 두 데이터베이스 시스템에 더 빨리 접근 할 수 있습니다.
물론 다른 구성 값에 대해서도 수행 할 수 있습니다.
그런 다음 구성 파일을 전달하기 전에 "_userName"으로 끝나는 모든 값을 스트라이프 할 수 있습니다.
그러나 결국 당신은 위 또는 다른 방법으로 구성 파일 (들)을 책임감있게 관리하는 "구성 파일의 소유자"입니다. 또한 각 배송 전에 고객이 직면 한 구성 파일을 비교해야합니다.
이렇게 부족한 문제를 돌보는 사람의 필요성을 제거 할 수는 없습니다.
구성 파일의 데이터 민감도 또는 사용중인 프로그래밍 언어 및 기타 여러 요인에 따라 달라질 수 있으므로 모든 경우에 작동하는 단일 솔루션은 없다고 생각합니다. 그러나 모든 환경에 대한 구성 파일을 소스 제어하에 유지하는 것이 중요하다고 생각하므로 언제 누가 변경되었는지 항상 알 수 있으며 문제가 발생하면 복구 할 수 있습니다. 그리고 그들은 할 것입니다.
그래서 여기에 내가하는 방법이 있습니다. 이것은 보통 nodejs 프로젝트 용이지만 다른 프레임 워크와 언어에서도 작동한다고 생각합니다.
내가하는 일은 configs프로젝트의 루트에 디렉토리를 만들고 그 디렉토리 아래에 소스 제어에서 모두 추적되는 모든 환경 (및 각 개발자의 환경에 대한 별도의 파일도 포함)에 대한 여러 파일을 보관합니다. 그리고 코드가 사용하는 실제 파일이 config프로젝트의 루트에 명명 되었습니다. 추적되지 않는 유일한 파일입니다. 그래서 이렇게 생겼어요
root
|
|- config (not tracked)
|
|- configs/ (all tracked)
|- development
|- staging
|- live
|- James
누군가가 프로젝트를 체크 아웃하면 추적되지 않은 config파일 에서 사용하려는 구성 파일을 복사하고 원하는 대로 편집 할 수 있지만 필요에 따라 다른 환경 파일에 커밋하기 전에 이러한 변경 사항을 복사 할 책임이 있습니다.
그리고 서버에서 추적되지 않은 파일은 단순히 해당 환경에 해당하는 추적 된 파일의 복사본 (또는 참조) 일 수 있습니다. JS에서는 해당 파일을 요구하는 한 줄만 있으면됩니다.
이 흐름은 처음에는 약간 복잡 할 수 있지만 큰 장점이 있습니다. 1. 백업없이 서버에서 구성 파일이 삭제되거나 수정되는 것에 대해 걱정할 필요가 없습니다. 2. 개발자가 자신의 사용자 지정 구성을 가지고있는 경우에도 마찬가지입니다. 기계와 그 기계는 당신이 설정 파일을 diff를 수있는 배포하기 전에 어떤 이유로 3에 대한 작동을 중지 development하고 staging, 예를 들어 누락 또는 파손 아무것도가 있는지.
나는 같은 문제에 직면했고 그것에 대한 해결책을 찾았습니다. 먼저 모든 파일을 중앙 저장소 (개발자 파일)에 추가했습니다.
따라서 개발자가 저장소에서 파일을 가져 오면 개발자 구성도 있습니다. 이 파일을 변경할 때 Git은 이러한 변경 사항을 인식하지 않아야합니다. 이렇게하면 변경 사항을 리포지토리에 푸시 / 커밋 할 수 없지만 로컬로 유지합니다.
git 명령을 사용하여이 문제를 해결했습니다 update-index --assume-unchanged.. Git에서 변경 사항을 무시해야하는 파일이 포함 된 프로젝트의 사전 빌드에서 실행되는 bat 파일을 만들었습니다. 다음은 bat 파일에 넣은 코드입니다.
IF NOT EXIST %2%\.git GOTO NOGIT
set fileName=%1
set fileName=%fileName:\=/%
for /f "useback tokens=*" %%a in ('%fileName%') do set fileName=%%~a
set "gitUpdate=git update-index --assume-unchanged"
set parameter= "%gitUpdate% %fileName%"
echo %parameter% as parameter for git
"C:\Program Files (x86)\Git\bin\sh.exe" --login -i -c %parameter%
echo Make FIleBehaveLikeUnchangedForGit Done.
GOTO END
:NOGIT
echo no git here.
echo %2%
:END
내 사전 빌드에서 다음과 같이 bat 파일을 호출했습니다.
call "$(ProjectDir)\..\..\MakeFileBehaveLikeUnchangedForGit.bat" "$(ProjectDir)Web.config.developer" "$(SolutionDir)"
나는 올바른 설정 파일을 web.config / app.config에 복사하는 bat 파일을 찾았습니다. 또한 사전 빌드에서이 bat 파일을 호출합니다. 이 bat 파일의 코드는 다음과 같습니다.
@echo off
echo Comparing two files: %1 with %2
if not exist %1 goto File1NotFound
if not exist %2 goto File2NotFound
fc %1 %2
if %ERRORLEVEL%==0 GOTO NoCopy
echo Files are not the same. Copying %1 over %2
copy %1 %2 /y & goto END
:NoCopy
echo Files are the same. Did nothing
goto END
:File1NotFound
echo %1 not found.
goto END
:File2NotFound
copy %1 %2 /y
goto END
:END
echo Done.
내 사전 빌드에서 다음과 같이 bat 파일을 호출했습니다.
call "$(ProjectDir)\..\..\copyifnewer.bat" "$(ProjectDir)web.config.$(ConfigurationName)" "$(ProjectDir)web.config