프로젝트 구성 파일을 처리하는 가장 쉬운 방법은 무엇입니까?
모든 프로젝트에 하나 이상의 구성 파일이있는 것은 매우 일반적입니다. 와 프로젝트를 공유 할 때마다 git
다음과 같은 문제가 발생합니다.
- 민감한 정보 (개발자마다 다른 DB 비밀번호 등)
- 작업 별 정보 (개발자가 일부 설정을 변경해야하는 특정 작업을 수행하는 경우)
개발자 특정 데이터가 주 저장소에 넘치지 않도록하려면 구성을 어떻게 든 무시해야합니다. 이제 몇 가지 사용 방법이 있으며 각각 몇 가지 결함이 있습니다.
.gitignore
구성 파일- 가장 기본적인 방법
- 개발자가 리포지토리를 복제 할 때 구성 파일이 누락되고 구성이 다시 생성 된 위치를 찾아야합니다.
- 구성 파일은 무시되지 않습니다. 여기에는 더미 정보가 포함되어 있으며 각 개발자는 추적을 해제하여 자신의 위치에
.git/info/exclude
넣거나git update-index --assume-unchanged ...
파일에 설정 합니다.- 저장소를 복제하는 모든 사람이 파일을 사용할 수 있습니다.
- 처음으로 git로 작업하는 사람들을 혼동시킬 수있는 고급 기술이 포함되어 있습니다.
- 누군가가 설정 파일을 실수로 커밋하면 사람들이 가져 오기 / 가져 오기를 허용하지 않습니다 (제외 항목은와 같은 방식으로 작동하지 않음
.gitignore
).
- 예를 들어 접미사가 붙은 구성 파일을 배포
_original
하고 실제 파일은.gitignore
. 그런 다음 각 개발자는 파일 이름을 실제 이름으로 바꿉니다.- 저장소를 복제하는 모든 사람이 파일을 사용할 수 있습니다.
- 응용 프로그램 전체에서 모든 구성을 검색하고 이름을 변경해야합니다.
이것을 처리하는 다른 더 나은 방법이 있습니까? 나는 내가 뭔가, 적어도 플러그인을 놓치고 있다고 생각합니다.
필터 드라이버 는 " 프로젝트에 비밀 키가있을 때 어떻게 GitHub로 푸시 할 수 있습니까? "에 자세히 설명 된대로 옵션 3을 구현하는 "자동"방법입니다 .
smudge
체크 아웃에 스크립트 의지 :
- 수정할 올바른 구성 파일 감지
- 필요한 정보를 가져오고 ( Git 저장소 외부에 가장 잘 보관 됨 ) 템플릿 값을 실제 값으로 대체합니다.
거기에서 개발자는 해당 구성 파일을 원하는대로 수정할 수 있습니다. 스크립트가 커밋시 해당 파일의 내용을 원래 (템플릿) 값으로 복원
하기 때문에 문제가되지 않습니다 clean
. 우연히 밀지 않습니다.
내가 작업 한 마지막 프로젝트에서 수행 한 방법은 사용자 로컬 구성 파일이있는 경우 사용자 로컬 구성 파일을로드하는 마스터 구성 파일을 갖는 것이 었는데, 지정되면 마스터에 설정된 기본값을 덮어 쓸 수 있고 존재하지 않는 경우 자체 구성 정보를 선언 할 수 있습니다. 마스터. 로컬 파일이 gitignore에 추가되었습니다. 이렇게하면 모든 공통 항목을 모두 공유 할 수 있고 일부 구성은 항상 존재하며 각 개발자는 로컬을 수정할 수 있습니다.
@VonC의 힌트로 작동하는 솔루션을 찾는 데 시간이 걸리기 때문에 Objective-C 헤더 파일에서 git clean 필터로 암호를 무시하는 방법에 대한 전체 예제가 있습니다.
Config.h
이것을 포함 하는 기본 구성 스크립트가 있다고 가정하십시오.// Change "12345" to your password #define kPass @"12345" #define kConstant 42
hidepass.sh
임계 줄과 일치 하는 스크립트 를 만들고 대신 기본 줄을 인쇄합니다.#!/bin/sh awk '{ if (/#define kPass/) print "#define kPass @\"12345\""; else print $0; }' exit 0
스크립트를 실행 가능하게 만들고 저장소에 추가하십시오.
이 줄을 추가하여 git에게 구성 파일을 필터링
.gitattributes
하도록 지시하십시오 (또한 .gitattributes를 저장소에 추가하십시오).Config.h filter=hidepass
청소하는 동안 git에게 hidepass 필터에
hidepass.sh
대한 스크립트를 사용하도록 지시하십시오 .git config filter.hidepass.clean ./hidepass.sh
이제 비밀번호를 변경할 수 Config.h
있지만 git은 항상 해당 행을 체크인시 기본 행으로 대체하기 때문에이 변경 사항을 커밋하지 않습니다.
이것은 한 줄 암호에 대한 빠른 솔루션입니다. 당신은 미쳐 버릴 수 있습니다. 예를 들어 무시할 줄을 특수 문자열로 끝내고 해당 문자열이있는 줄을 확인합니다.
내가 해본 프로젝트에서는 기본 구성이 있으며 개발자는 버전 제어 (구성에 대한 규칙) 외부의 특정 위치에 자신의 구성을 가지고 있습니다. 후자의 값은 전자의 값을 재정의하는 데 사용됩니다.
구성의 중요한 세부 정보에 암호화를 사용하기 시작했습니다. 자동화 된 배포를 위해 프로덕션 구성에서 암호 처리
git의 경우 git attributes filter attribute
자동화 된 방식으로 로컬 값의 교체와 민감한 값의 암호 해독을 모두 수행 할 수 있습니다 .
production.yml
및 하위 모듈 저장소에 대한 액세스가 제한된 하위 모듈을 가질 수도 있습니다 .
제가 생각할 수있는 한 가지는 위의 방법 2와 방법 1과 유사합니다. 구성 파일, 사용자 업로드 파일 등의 디렉토리와 같이 사이트 고유의 복잡한 것을 저장하는 디렉토리가있는 경우
구성 파일 자체 만 버전 제어에서 제외되지만 사이트에서 실제로 사용하는 것과 약간 다른 이름이 지정된 더미 복사본이 있으며이 파일에는 구성 매개 변수에 대한 자세한 지침과 이름이 바뀐 복사본을 만드는 방법이 포함되어 있습니다.
예를 들어 "site_profile"디렉토리가 있다고 가정합니다. 이 디렉토리에서 "README.settings.php"라는 파일을 만들고 사용자가 업로드 한 파일 (관리자 및 프런트 엔드 사용자 모두)이 포함 된 "files"디렉토리를 만듭니다. 이 모든 것은 버전 관리하에 있습니다.
그러나 사이트는 여기에 존재하지 않는 "settings.php"에서 설정을 실행합니다. 그러나 "README.settings.php"의 이름을 "settings.php"로 바꾸려면 필요한 구성 파일을 갖게됩니다 (물론 사용자 지정 설정을 입력 한 후).
This will allow you to tell the other developers what they need out of their config file while keeping your own config file out of the mix. Just set your config file to be ignored or never do a blanket commit for that directory and lower.
Its what we do with Drupal sites where I work and it works really well.
For the two cases you mention:
sensitive information (each developer have different DB passwords etc)
Write your scripts to so that these sensitive files are stored in the developer's home directory, rather than in the project directory.
task specific information (when developer works on certain task where one needs to change some settings)
I usually have the default settings checked into the repository, and then when you prepare your commits, you can easily check if you've modified any of those settings, and revert them before you commit.
I saved my local config changes to a git stash. I use git stash apply rather than pop, so that I never remove it from the stash queue. That way I can use reset --hard whenever I feel like it.
Having no experience with Git, but having dealt with the same issues in other contexts (Hibernate login creds in a Spring JUnit suite, or ANT scripts), for anything that is user-specific or depends on a user's local environment:
- Have a README listing those dependencies and how to configure your local env to run the script.
- Replace those dependencies in your conf with calls to system properties, or some framework way to pull in external values. In an ANT script, for instance, you can replace strings with
<sysproperty key="jdbc.username" value="${jdbc.username}"/>
, wherejdbc.username
is a system variable (that you can set in Eclipse).
Developers can check in whatever they want, because the conf is user-agnostic.
A lot of good options listed. A few more options to mention:
- Add all configs to .gitignore. Then have a separate git project, with the just the configuration files. (Keep this GIT #2 in a totally different folder.) In this GIT #2, make a few scripts similar to
apply-config /path/to/my_git1
,save-config /path/to/my_git1
which copy in, or save configuration files for the main GIT repo.- I prefer this to using submodules. I've found working with submodules cumbersome across a large team.
- You can then track configurations, or use multiple GIT repos for things like production settings, debug settings, more optimized settings, etc.
- Uses one tool (GIT) that everyone understands.
- 나는 홈 폴더에서 DB 연결 정보와 같은 민감한 정보를 찾는 아이디어를 좋아합니다. (@avh에서 언급)
- devOps의 경우 배포 및 설정 자동화를 위해 Ansible / Salt / Chef / Puppet과 같은 것을 고려할 수 있습니다.
The Twelve-Factor App 에서 널리 사용되는 또 다른 매우 일반적인 옵션 은 구성 변수를 파일에 하드 코딩하지 않고 환경 변수에서로드하는 것입니다. 이렇게하면 저장소의 파일에 특별한 처리가 필요하지 않습니다.
'Nice programing' 카테고리의 다른 글
확장 가능한 소프트웨어 (플러그인 아키텍처)를 설계하는 방법은 무엇입니까? (0) | 2020.10.30 |
---|---|
AngularJS 인증 + RESTful API (0) | 2020.10.30 |
PHP 코드 리팩토링을위한 도구 (0) | 2020.10.30 |
Docker가 포트 바인딩에 IPv4를 사용하도록 설정 (0) | 2020.10.30 |
C에서 "[*]"(별표 수정 자)는 무엇을 의미합니까? (0) | 2020.10.30 |