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

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

---

일반적인 웹 앱과 파일 구성이 있다고 가정 해 보겠습니다. 프로젝트에서 작업하는 모든 개발자는 개발 상자에 대해 하나의 버전을 갖게되며 개발, 제품 및 단계 버전이 있습니다. 소스 제어에서 이것을 어떻게 처리합니까? 이 파일을 전혀 체크인하지 않거나 다른 이름으로 확인하거나 모두 멋진 작업을 수행합니까?

---

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

일반적으로 재정의 파일이 작을수록 더 좋지만 매우 비표준 환경의 개발자를 위해 항상 더 많은 설정을 포함 할 수 있습니다.

---

구성 은 코드이며 버전을 지정해야합니다. 구성 파일은 사용자 이름을 기반으로합니다. 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 등에 있음을 알려주 는 정보의 한 줄을 읽습니다 .이 항목은 모든 워크 스테이션과 서버에 있습니다.

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

---

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

새 값 / 속성을 추가 할 때 고통을 유발할 수있는 구성 파일 간의 중복 양을 줄입니다.

---

나는 항상 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를 해당 환경에 적합한 구성 파일로 덮어 쓰는 작업이 있어야합니다. 파일이 압축 된 경우 해당 빌드에서 관련없는 파일을 삭제해야합니다.

---

@Grant가 맞습니다.

I'm on a team with close to 100 other developers, and our config files are not checked into source control. We have versions of the files in the repository that are pulled with each check out but they don't change.

It's worked out pretty well for us.

---

I version control it, but never push it to the other servers. If the production server requires a change, I make that change directly to the config file.

It may not be pretty, but it works just fine.

---

The checked-in, plain-vanilla version of app/web.config should be generic enough to work on all developer machines, and be kept up to date with any new setting changes, etc. If you require a specific set of settings for dev/test/production settings, check in separate files with those settings, as GateKiller stated, with some sort of naming convention, though I usually go with "web.prod.config", as not to change the file extension.

---

We use a template config file that is checked in to version control and then a step in our automated build to replace specific entries in the template file with environment-specific settings. The environment-specific settings are stored in a separate XML file that is also under version control.

We're using MSBuild in our automated build, so we use the XmlUpdate task from MSBuild Community Tasks to update the values.

---

For a long time, I have done exactly what bcwood has done. I keep copies of web.dev.config, web.test.config, web.prod.config, etc. under source control, and then my build/deploy system renames them automatically as it deploys to various environments. You get a certain amount of redundancy between the files (especially with all of the asp.net stuff in there), but generally it works really well. You also have to make sure that everyone on the team remembers to update all the files when they make a change.

By the way, I like to keep ".config" at the end as the extension so that file associations do not get broken.

As far as local developer versions of the config file, I always try my best to encourage people to use the same local settings as much as possible so that there is no need to have your own version. It doesn't always work for everyone, in which case people usually just replace it locally as needed and go from there. It's not too painful or anything.

---

On our project we have configuration stored in files with a prefix then our build system pulls in the appropriate configuration based on the current system's hostname. This works well for us on a relatively small team, allowing us to apply config changes to other people's files if/when we add a new configuration item. Obviously this definitely doesn't scale to open source projects with an unbounded number of developers.

---

We have two problems here.

• Firstly we have to control the configuration file that is shipped with the software.

  It is all two easy for a developer to check in an unwanted to change to the master config file, if they are using the same file in the devolvement environment.

  On the other side, if you have a separate configuration file that is included by the installer, it is very easy to forget to add a new setting to it, or to let the comments in it get out of sync with the comments in the devolvement configuring file.

• Then we have the problem that developers have to keep there copy of the configuration file up-to-date as other developers add new configuration settings. However some settings like database connection strings are different for each developer.

• There is a 3rd problem the question/answers do not cover. How do you merge in the changes a customer have make to your configuration file when you install a new version of your software?

I have yet to see a good solutions that works well in all cases, however I have seen some partial solutions (that can be combined in different combinations as needed) that reduces the problem a lot.

• Firstly reduce the number of configuration items you have in your main configuration file.

  If you don’t have a need to let your customers change your mappings, use Fluent NHibernate (or otherwise) to move the configuration into code.

  Likewise for depency injection setup.

• Split up the configuration file when possible, e.g. use a separate file to configure what Log4Net logs.

• Don’t repeat items between lots of configuration files, e.g. if you have 4 web applications that are all installed on the same machine, have a overall configuration file that the web.config file in each application points to.

  (Use a relative path by default, so it is rare to have to change the web.config file)

• Process the development configuration file to get the shipping configuration file.

  The could be done by have default values in the Xml comments that are then set in the configuration file when a build is done. Or having sections that are deleted as part of the process of creating the installer.

• Instead of just having one database connection strings, have one per developers.

  E.g first look for “database_ianr” (where ianr is my username or machine name) in the configuration file at run time, if it is not found, then look for “database”

  Have a 2nd level "e.g. -oracle or -sqlserver" make it quicker for developers to get to both database systems.

  This can of course also be done for any other configuration value.

  Then all values that end in “_userName” can be striped out before shipping the configuration file.

However in the end what is you is a “owner of configuration file” that takes the responsibly of managing the configuration file(s) as above or otherwise. He/She should also do a diff on the customer facings configuration file before each shipment.

You can’t remove the need for a caring person some this short of problem.

---

I don't think there's a single solution that works for all cases as it may depend on the sensitivity of data in the config files, or the programming language you're using, and so many other factors. But I think it's important to keep the config files for all environments under source control, so you can always know when it was changed and by whom, and more importantly, be able to recover it if things go wrong. And they will.

So here's how I do it. This is for nodejs projects usually but I think it works for other frameworks and languages as well.

What I do is create a configs directory at the root of the project, and under that directory keep multiple files for all environments (and some times separate files for each developer's environment as well) which are all tracked in source control. And there is the actual file that the code uses named config at the root of the project. This is the only file that is not tracked. So it looks like this

root
|
|- config (not tracked)
|
|- configs/ (all tracked)
    |- development
    |- staging
    |- live
    |- James

When someone checks out the project he copies the config file he wants to use in the untracked config file and he is free to edit it as he wishes but is also responsible to copy these changes before he commits to the other environment files as needed.

And on servers, the untracked file can simply be a copy (or reference) of the tracked file corresponding to that environment. In JS you can simply have 1 line to require that file.

This flow may be a little complicated at first but it has great advantages: 1. You never have to worry about a config file getting deleted or modified on the server without having a backup 2. The same if a developer has some custom config on his machine and his machine stops working for any reason 3. Before any deployment you can diff the config files for development and staging for example and see if there's anything missing or broken.

---

We just keep the production config file checked in. It's the developer's responsibility to change the file when they pull it out of source safe for staging or development. This has burnt us in the past so I wouldn't suggest it.

---

I faced that same problem and I found a solution for it. I first added all the files to the central repository (also the developer ones).

So if a developer fetches the files from the repository the developer config is also there. When changing made to this file, Git should not be aware of these changes. That way changes cannot be pushed/committed to the repository but stay locally.

I solved this by using the git command: update-index --assume-unchanged. I made a bat file that is executed in the prebuild of the projects that are containing a file whose changes should be ignore by Git. Here is the code I put in the bat file:

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

In my prebuild I would made a call to the bat file, for example:

call "$(ProjectDir)\..\..\MakeFileBehaveLikeUnchangedForGit.bat" "$(ProjectDir)Web.config.developer" "$(SolutionDir)"

I found on SO a bat file that copies the correct config file to the web.config/app.config. I also call this bat file in the prebuild. The code for this bat file is:

@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.

In my prebuild I would made a call to the bat file, for example:

call "$(ProjectDir)\..\..\copyifnewer.bat" "$(ProjectDir)web.config.$(ConfigurationName)" "$(ProjectDir)web.config

참고URL : https://stackoverflow.com/questions/6009/how-do-you-deal-with-configuration-files-in-source-control