소스 제어에서 구성 파일을 어떻게 처리합니까?

StackOverflow https://stackoverflow.com/questions/6009

  •  08-06-2019
  •  | 
  •  

문제

일반적인 웹 앱과 파일 구성이 있다고 가정해 보겠습니다.프로젝트에 참여하는 모든 개발자는 개발 박스에 대해 하나의 버전을 갖게 되며 개발, 프로덕션 및 스테이지 버전이 있습니다.소스 제어에서 이 문제를 어떻게 처리합니까?이 파일을 전혀 체크인하지 않거나, 다른 이름으로 확인하거나, 완전히 멋진 작업을 하시겠습니까?

도움이 되었습니까?

해결책

과거에 내가 한 일은 소스 제어에 체크인된 기본 구성 파일을 갖는 것입니다.그런 다음 각 개발자는 소스 제어에서 제외되는 자체 재정의 구성 파일을 갖습니다.앱은 먼저 기본값을 로드한 다음 재정의 파일이 있는 경우 해당 파일을 로드하고 기본 파일보다 우선적으로 재정의의 모든 설정을 사용합니다.

일반적으로 재정의 파일은 작을수록 좋지만 매우 비표준 환경을 사용하는 개발자에게는 항상 더 많은 설정이 포함될 수 있습니다.

다른 팁

해당 파일의 버전을 지정하지 마세요.템플릿 등의 버전을 지정하세요.

구성 ~이다 코드를 작성하고 버전을 지정해야 합니다.구성 파일은 사용자 이름을 기반으로 합니다.UNIX/Mac 및 Windows 모두에서 사용자의 로그인 이름에 액세스할 수 있으며 이것이 프로젝트에 고유한 한 괜찮습니다.환경에서 이를 재정의할 수도 있지만 ~해야 한다 버전 관리 모든 것.

또한 이를 통해 다른 사람의 구성을 검사할 수 있어 빌드 및 플랫폼 문제를 진단하는 데 도움이 될 수 있습니다.

우리 팀에서는 각 환경(web.config.dev, web.config.test, web.config.prod)에 대해 별도의 구성 파일 버전을 유지합니다.배포 스크립트는 올바른 버전을 복사하여 이름을 web.config로 바꿉니다.이러한 방식으로 각 환경의 구성 파일에 대한 완전한 버전 제어가 가능하고 비교 등을 쉽게 수행할 수 있습니다.

현재 다음과 같은 확장명이 추가된 "템플릿" 구성 파일이 있습니다.

web.config.rename

그러나 중요한 변경 사항이 변경된 경우 이 방법에 문제가 있을 수 있습니다.

우리가 사용하는 솔루션은 단일 구성 파일(web.config/app.config)만 갖는 것이지만 파일에 모든 환경에 대한 설정이 포함된 특수 섹션을 추가합니다.

이있다 로컬, 개발, QA, 생산 각 섹션에는 구성 파일의 해당 환경과 관련된 구성 키가 포함되어 있습니다.

이 모든 것을 작동하게 만드는 것은 다음과 같은 어셈블리입니다. xxx.환경 이는 애플리케이션이 어떤 환경에서 작동하는지 알려주는 모든 애플리케이션(winforms 및 webforms)에서 참조됩니다.

xxx.Environment 어셈블리는 다음에서 한 줄의 정보를 읽습니다. 기계.구성 DEV, QA 등에 있음을 알려주는 특정 머신의이 항목은 모든 워크스테이션과 서버에 존재합니다.

도움이 되었기를 바랍니다.

템플릿 접근 방식에 +1.

그러나이 질문은 태그 git이 있기 때문에 분산 된 대체 스프링이 떠오르고, 여기에는 사용자 정의가 개인 테스트 지점에 보관됩니다.

A---B---C---D---           <- mainline (public)
     \       \
      B'------D'---        <- testing (private)

이 체계에서 메인 라인에는 최소한의 조정이 작동하기 위해 필요한 "템플릿"구성 파일이 포함되어 있습니다.

이제 개발자/테스터는 구성 파일을 Heart의 콘텐츠에 조정하고 개인 테스트 브랜치 (예 :B' = B + 사용자 정의).Mainline이 발전 할 때마다 쉽게 테스트로 병합하여 D '(= D + 병합 버전 B의 사용자 정의)와 병합 된 커밋이 발생합니다.

이 구성표는 "템플릿" 구성 파일이 업데이트될 때 정말 빛을 발합니다.양쪽의 변화는 합병되며 호환되지 않는 경우 충돌 (또는 테스트 실패)이 발생할 가능성이 매우 높습니다!

이전에 템플릿을 사용한 적이 있습니다.web.dev.config, web.prod.config 등이 있지만 이제는 '파일 재정의' 기술을 선호합니다.web.config 파일에는 대부분의 설정이 포함되어 있지만 외부 파일에는 db 연결과 같은 환경별 값이 포함되어 있습니다.에 대한 좋은 설명 폴 윌슨의 블로그.

나는 이것이 새로운 값/속성을 추가할 때 고통을 유발할 수 있는 구성 파일 간의 중복 양을 줄인다고 생각합니다.

저는 항상 모든 버전의 구성 파일을 소스 제어의 web.config 파일과 동일한 폴더에 보관해 왔습니다.

예를 들어

web.config
web.qa.config
web.staging.config
web.production.config

나는 web.config.production 또는 Production.web.config와는 반대로 이 명명 규칙을 선호합니다.

  • 파일 이름별로 정렬하면 파일이 함께 유지됩니다.
  • 파일 확장자별로 정렬하면 파일이 함께 유지됩니다.
  • 파일이 실수로 프로덕션에 푸시된 경우 IIS에서 *.config 파일이 제공되지 않도록 방지하므로 http를 통해 내용을 볼 수 없습니다.

기본 구성 파일은 자신의 컴퓨터에서 로컬로 애플리케이션을 실행할 수 있도록 구성되어야 합니다.

가장 중요한 것은 이러한 파일이 형식을 포함한 모든 측면에서 거의 100% 동일해야 한다는 것입니다.들여쓰기를 위해 한 버전에서는 탭을 사용하고 다른 버전에서는 공백을 사용해서는 안 됩니다.파일 간의 차이점을 정확히 확인하려면 파일에 대해 diff 도구를 실행할 수 있어야 합니다.나는 파일을 비교하기 위해 WinMerge를 사용하는 것을 선호합니다.

빌드 프로세스에서 바이너리를 생성할 때 web.config를 해당 환경에 적합한 구성 파일로 덮어쓰는 작업이 있어야 합니다.파일이 압축된 경우 해당 빌드에서 관련 없는 파일을 삭제해야 합니다.

@그랜트 말이 맞아요.

저는 100명에 가까운 개발자로 구성된 팀에 속해 있으며 구성 파일이 소스 제어에 체크인되지 않았습니다.저장소에는 체크아웃할 때마다 가져오는 파일 버전이 있지만 변경되지는 않습니다.

우리에게는 꽤 잘 풀렸습니다.

버전을 관리하지만 다른 서버로 푸시하지는 않습니다.프로덕션 서버에 변경이 필요한 경우 구성 파일을 직접 변경합니다.

예쁘지는 않을 수도 있지만 잘 작동합니다.

app/web.config의 체크인된 일반 바닐라 버전은 모든 개발자 컴퓨터에서 작동할 수 있을 만큼 일반적이어야 하며 새로운 설정 변경 등을 통해 최신 상태로 유지되어야 합니다.개발/테스트/프로덕션 설정에 대한 특정 설정 세트가 필요한 경우 GateKiller가 설명한 대로 일종의 명명 규칙을 사용하여 해당 설정이 포함된 별도의 파일을 체크인하십시오. 하지만 일반적으로 "web.prod.config"를 사용하지는 않습니다. 파일 확장자를 변경하려면 .

버전 제어에 체크인된 템플릿 구성 파일을 사용한 다음 자동화된 빌드의 단계를 사용하여 템플릿 파일의 특정 항목을 환경별 설정으로 바꿉니다.환경별 설정은 역시 버전 제어 대상인 별도의 XML 파일에 저장됩니다.

우리는 자동화된 빌드에서 MSBuild를 사용하고 있으므로 XmlUpdate 작업을 사용합니다. MSBuild 커뮤니티 작업 값을 업데이트합니다.

오랫동안 나는 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가없는 상태에서 구성 파일이 서버에서 삭제되거나 수정되는 것에 대해 걱정할 필요가 없습니다.개발자가 자신의 컴퓨터에 사용자 정의 구성이 있고 기계가 어떤 이유로 든 작동하지 않는 경우에도 마찬가지입니다.배포하기 전에 구성 파일을 비교할 수 있습니다. 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)"

SO에서 올바른 구성 파일을 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
라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top