버전 관리 및 개인 구성 파일

우리 프로젝트는 사용자 별 구성 파일을 사용합니다. 이 파일은 현재 사용자마다 다르기 때문에 버전 관리 상태가 아닙니다. 문제는 개발자가 구성이 필요한 새 모듈을 추가하거나 기존 모듈의 이름을 변경할 때마다 개인 구성 파일이 업데이트되지 않기 때문에 다른 개발자에게 오류가 발생한다는 것입니다.

이 문제를 해결하기 위해 두 가지 구성 파일, 즉 버전 제어 상태에 있고 새 모듈을 추가하는 각 개발자가 정기적으로 업데이트하는 기본 / 글로벌 구성 파일과 보관할 개인 구성 파일로 작업하는 것을 생각했습니다. 버전 제어 및 사용자 별 변경 사항 만 포함합니다.

그러나 이것은 여전히 ​​임시 솔루션처럼 보입니다.

더 나은 솔루션을 제안 할 수 있습니까?

전문가들은 무엇을합니까?

여기에 이미 좋은 대답이 있지만 대부분은 문제의 근본 원인을 놓치고 있습니다. 사용자 구성 파일에는 사용자 특정 정보 이상이 포함되어있는 것으로 보이며 다른 곳에서는 버전 제어하에있는 중복 정보도 포함되어 있습니다. 모듈 이름과 같은 다른 파일에있을 수 있습니다.

두 가지 가능한 솔루션을 여기에서 생각할 수 있습니다.

• 그 정보를 엄격하게 분리하십시오. 예를 들어, 사용자 설정에서 모듈 이름을 사용하지 마십시오. ID 번호 (예 : GUID)를 사용하여 모듈을 참조하고 해당 ID 번호가 모듈에 지정된 후에 변경되지 않도록하십시오. 물론, 그것은 아마도 사용자 설정 파일이 현재 가지고있는 단순함을 잃어 버릴 것이라는 단점이 있습니다. 일반 텍스트 편집기를 사용하는 대신 구성 파일을 편집하려면 GUI 도구를 작성해야합니다.

• 구성 파일 형식에 버전 번호를 제공하고 모듈 이름과 같은 것이 변경 될 때마다 새 버전 번호를 지정하십시오. 그런 다음 버전 번호를 확인하는 업그레이드 스크립트를 제공하고 구성 파일이 최신이 아닌 경우 파일에서 찾은 모든 모듈 이름을 변경하고 나중에 버전 번호를 증가시킵니다. 이를 자동화 할 수 있으므로 업그레이드 프로세스가 팀의 일상 업무를 방해하지 않습니다.

편집 : 게시물을 다시 읽은 후 새 모듈이 추가되었지만 이름이 변경되지 않는 한 귀하의 솔루션이 합리적이라고 생각합니다. 위에서 쓴 내용은 나중에 모듈 이름이나 기존 모듈의 구성 구조를 변경할 수 있습니다. 그러나 당신이 그것을 필요로하지 않는다면, 나는 가장 간단한 해결책을 고수 할 것입니다.

합리적인 해결책입니다.

새로운 구성 요소의 초기 값을 지정하는 방법이 필요합니다. 이것들은 어딘가에 저장되어야하며, 전역적인 읽기 전용 구성 파일이 확실한 선택입니다.

그런 다음 각 사용자가 개인 구성을 변경할 때 이러한 변경 사항을 로컬 사본에 씁니다.

코드는 전역 구성을 먼저 읽고 변경된 값을 덮어 쓰려면 사용자 별 구성을 읽어야합니다. 이것은 로컬을 읽는 것보다 훨씬 간단하고 설정되지 않은 것을 해결하려고 시도하므로 전역 설정 파일에서 읽을 필요가 있습니다.

스토리지에 XML과 같은 것을 사용하는 경우 설정을 제거하는 경우를 처리하는 것에 대해 걱정할 필요가 없습니다. 파일의 사용자 사본에서 요청하지 않으며 저장시 파일을 다시 작성하면 변경 후 애플리케이션을 처음 사용할 때 제거됩니다.

우리는 다소 흥미로운 해결책을 가지고 있습니다. 우리는 주로 PHP 개발자이므로 PHP로 작성된 자동화 된 작업을 생성 할 수있는 Phing을 사용합니다. 따라서 일반적인 svn 업데이트를 수행하는 대신 svn update를 호출하는 "phing update"를 수행합니다. 그런 다음 설정을 적절한 변수 (예 : 구성)로 바꿉니다.

$db_user = "${test.db_user}";

따라서 구성 파일은 모두 흥미로운 구문으로 버전이 지정된 다음 특정 인스턴스에 대해 버전이 지정되지 않은 임시 구성 파일을 생성하여 해당 "변수"를 버전이없는 ini 파일에 지정된 버전이없는 설정으로 바꿉니다. 이러한 방식으로 사용자 별 파일을 수정하고 다른 작업 복사본 전체에 변경 사항을 적용 할 수 있습니다.

구성 파일에서 값을 찾을 수없는 경우 코드의 기본 설정이 프로그램에 있어야합니다. 이런 방식으로 새로운 것이 추가 될 때 중단되지 않고 업그레이드 경로가 더 매끄러 워지며 구성 파일을 엉망으로 만들 때 사용자가 대체 할 수 있습니다.

더 복잡한 또 다른 예는 프로그램 시작 또는 다른 주요 지점에서 초기화 모듈을 사용하여 구성 파일을 열고 누락 된 기본값을 추가하는 것입니다. 그러나 이것은 상당히 무거워 보입니다.

개인 구성 파일 (구성 파일 형식의 버전 번호)에 버전 번호를 입력하십시오.

개인 구성 파일을 처리하는 코드에서 버전 번호를 확인하고 최신 버전이 아닌 경우 업데이트 절차를 실행하십시오. 따라서 기본적으로 기존 구성 파일을 손상시키는 변경을 수행하는 사람은 구성 파일 형식의 버전 번호를 충돌시키고 이전 버전의 구성 파일 (이름 변경 섹션 등)을 업데이트하고 다시 저장하는 절차를 작성해야합니다. 그들.

어쨌든 최종 사용자를 위해 이와 같은 프로세스를 원할 것이므로 개발자의 삶을 편하게 만드는 데 사용할 수도 있습니다.

일반적으로 내가 본 방법은 기본값을 가진 구성 파일을 저장소에 체크인하는 것입니다. 예를 들어 테스트 서버에 필요한 값일 수 있습니다. 그런 다음 개발자가 파일을 체크 아웃하면 모든 값을 갖습니다. 새 필드가 추가되거나 필드가 제거되면 병합에서 처리됩니다. 개발자는 대상 서버에 필요한 값을 체크인하고 개인 개발 환경에 대한 필드의 다른 변경 사항은 체크인하지 않습니다.

병합이 올바르게 수행되도록주의를 기울이지 만, 나에게는 꽤 안전 해 보입니다.

여기서하는 것은 설정 블록을 만드는 것입니다. Zend에서 다음과 같이 할 수 있습니다 :

[production]
key1: parameter1
key2: parameter2

[testing: production]
key1: parameter2
key3: parameter4

즉, 테스트는 프로덕션을 상속하고 key3으로 확장합니다. 각 개발자는 환경을 설정하기 만하면됩니다 (이 경우 테스트 또는 프로덕션).

이것은 게시물을 기반으로 한 유용한 솔루션입니다. 암호를 소스 제어로 유지

요약하면 전략은 "구성 파일의 암호화 된 버전을 소스 제어로 유지 한 다음 사용자가 해당 데이터를 암호화하고 해독 할 수있는 수단을 제공하는 것"입니다.

1. 더미 통신 파일을 생성하고 .gitignore 파일로 만듭니다.
2. 구성 파일을 암호화하고 해독 할 수있는 makefile을 작성하십시오.
3. makefile 및 암호화 된 구성 파일을 저장소에 저장하십시오.
4. makefile은 암호를 요청하고 암호를 위해 작성자에게 연락하는 방법을 묻습니다.
5. 프로젝트를 빌드 할 때 makefile이 실행되지 않은 경우 console.error ( "구성 파일 [conf / settings.json] 누락! 실행하는 것을 잊었습니까 make decrypt_conf?");
6. 구성 파일이 최신인지 확인하기 위해 점검이 설명됩니다.

우리는 이와 같은 구성 문제를 처리하는 Config 라는 도구를 만들었습니다 . 마스터 구성 파일 1 개를 작성 (또는 가져 오기)하면됩니다. 그런 다음 로컬이라는 환경을 작성하십시오. 로컬 환경에서 여러 인스턴스를 작성하십시오 (사용자 당 하나의 인스턴스). 새 구성 항목을 추가하거나 모듈 이름을 수정하는 등 보드 전체에 공통적 인 변경이 필요한 경우 변경하면 보드 전체에 적용됩니다. 인스턴스 / 사용자를 변경하려면 해당 구성 값을 변수로 만든 다음 변수를 변경하십시오. 이 변경 사항은 인스턴스 / 사용자에게만 적용됩니다. 이 모든 것은 버전 관리하에 있습니다. 푸시 또는 풀을 통해 구성 파일을 배포합니다. pull 옵션은 git pull과 비슷하지만 특정 인스턴스 / 사용자에 해당합니다.

구성은 사용자 간의 구성 비교, 검색, 태그 지정, 유효성 검사 및 워크 플로와 같은 추가 기능을 제공합니다. 클라우드를 아직 준비하지 않은 사람들에게는 실제로 SaaS가 아니지만 온 프레미스 계획이 있습니다.