개밥을 할 때 다음 버전의 도구를 사용하기 시작하는 것이 언제 적절한가요?

특히, DVCS와 빌드 시스템을 통합하는 도구를 개발하고 있지만 "메타"도구 (컴파일러, VCS, 빌드 시스템, 테스트 러너 등)를 개발하는 모든 사람이 직면 한 문제를 이미지화했습니다. "dogfooding"을 통해 발전하고 싶다 .

내 질문은 : 분기 워크 플로우를 사용하는 스크럼 스타일 릴리스 프로세스 에서 도구의 개발주기에서 어떤 시점에서 최신 버전의 도구를 사용하기 시작합니까?

다음 사이에 균형을 만드는 프로세스를 찾고 있습니다.

• 지속적으로 develop도구 버전을 사용하십시오 . 변경 사항이 통합됨에 따라 자체 개발을 중단하고 있습니다.

• 지속적으로 사용 master밝히기 시험 사용을 통해 문제 이미 출시 된 문제입니다 : 도구의 버전.

가장 먼저 할 일은 매우 철저한 자동화 된 오프라인 회귀 테스트를하는 것입니다. 공식적으로 사용하는 데 필요한 최소한의 테스트를 통과해야합니다.

둘째, 자동화 된 테스트에서 포착 할 수없는 문제에 대해 이전 작업 버전으로 대체 할 수있는 간단한 방법이 필요합니다.

예를 들어, Linux 커널은 한동안 사용자 정의 패치되었습니다. 커널을 사용하려는 컴퓨터에서 커널을 패치하고 컴파일하여 잘못된 커널을 만들면 개발 환경을 잃을 수있었습니다. 따라서 GRUB 메뉴에 항상 잘 알려진 커널을 유지해야했기 때문에 실수를 한 경우 간단한 재부팅으로 좋은 개발 환경으로 돌아 왔습니다.

팀과의 조정은 까다로운 일이지만, 누구나 대체를 시작하고 그 이유를 알리는 것이 문제라고 생각합니다. 버전 관리에서이를 지정하는 한 가지 방법은 last_known_good지점 과 같은 워크 플로 사이 develop또는 master워크 플로 와 같은 것 입니다. 빌드를 성공적으로 dogfood 할 때까지 아무것도 밀리지 않습니다.

이 도구를 사용하여 생산 품질의 소프트웨어를 생산하는 경우 (특히 재귀 적으로 사용하는 경우, 즉 자체 개발하는 경우), 사전 테스트 노력을 늘리고 릴리스가 안정 될 때까지 개밥을 기다립니다. 프로덕션 코드를 사용하여 프로덕션 코드를 위반하지 않을 것이라고 확신합니다.

마스터 버전이 그 수준의 신뢰를 가질 때까지 기다려야한다면 그렇게하십시오.

힘내도 그러한 도구이며 분명히 개밥을합니다. 그러나 환경에 따라 그 정도가 다릅니다. 퍼블릭 서버는 릴리즈 만 실행하는 반면 개발자는 일반적으로 next(개발 프로젝트의 git 프로젝트 이름) 또는 pu(개발보다 개발이 더 많은) 작업을합니다. 어떤 문제에 의해 차단되는 모든 개발자는 다시 갈 수 next또는 master그들이 무언가에 의해 차단되고 주요 저장소가 영향을받지 때마다 문제가 그것을 참조하여 세척 할 수 있도록, 또는 마지막 릴리스.

분기 모델은 약간 다른 이름으로 위와 유사합니다. master큰 릴리스가 수행되는 작업은 maint다음 지점 릴리스의 릴리스 분기이며, next전체 다음 병합이 아닌 다음에 이미 통합 된 후 기능이 마스터에 별도로 병합 될 수 있다는 점에서 약간의 차이점이 있습니다.

추가 지점이 pu있습니다. 통합을 위해 고려되는 모든 기능 분기를 병합하여 작성합니다 next(분기는 매번 삭제되고 다시 작성 됨). IIRC 테스트 스위트를 통과 한 경우에만 게시됩니다. 마지막으로 관리자 인 Junio가 정기적으로 수동으로 빌드하기 위해 스크립트를 실행하고 있었지만 이러한 스크립트는 매일 밤 지속적으로 통합하여 실행될 수 있으며 Gerrit 도 자동으로 생성 한다고 생각 합니다.

그래서 그런 종류의 대답입니다. 개발 환경에서 가장 많은 개발 버전을 dogfood하지만 릴리스 빌드에는 이전 릴리스를 사용합니다.

수락 된 답변을 기반으로 분기 워크 플로 를 확장하여 분기와 다음과 유사한 분기를 유지합니다.

• master: release-*마감시 병합
• dogfood: 지점에서 master; 개밥을하는 동안 식별 된 수정 프로그램을 포함합니다. develop소프트웨어가 내부 용으로 "안정한"것으로 간주 될 때 부터 합병 ; 필요한 경우이 지점의 머리를 제 시간에 다시 이동할 수 있습니다
• develop: 지점에서 master; 지속적인 변경, 버그 수정 및 합병 dogfood및 feature-*지점 포함
• feature-*: 지점에서 develop; 특정 새로운 기능에 대한 변경 사항 포함
• release-*: dogfood소프트웨어가 외부 용으로 "안정한"것으로 간주 될 때의 분기 ; 와 병합하기 전에 설명서 업데이트 및 사소한 버그 수정 포함master