수은 코드 검토를위한 권장 프로세스

우리는 일반적으로 Perforce와 SmartBear의 Code Collaborator를 사용 Big Corp했으며 이제 특정 프로젝트에 Mercurial을 사용할 것입니다.

Code Collaborator는 Mercurial (버전 5를 사용 중)을 지원하며 최선의 시간 (커밋 / 푸시 투 서버 중) 프로세스가 코드 검토에 가장 적합한 시간을 결정하려고합니다.

감사

code-reviews mercurial

— 크 브릴 라크
소스

아마도 두 질문을 분리해야합니다. (a) 여기에 속하지만 (b) 아마 stackoverflow 또는 serverfault에 속할 것입니다

— blueberryfields

감사합니다 @blueberryfields. 실제로 문제를 해결했습니다. 문제는 bin / hg.cmd 파일이 경로에 있고 EXE가 없다는 것입니다.

— cbrulak

답변:

실제로 우리 회사에서는 최근에 거의 똑같은 일을 겪었습니다. 우리가 한 일은 다음과 같습니다.

우리는 모든 저장소의 중앙 결정 사본을 하나의 서버에 보관합니다. 개발자가 코드를 "체크 아웃"하려고 할 때이 서버로 이동하여 리포지토리에서 복제합니다. 마찬가지로 개발주기가 완료되면 코드가 해당 저장소로 푸시됩니다.
안정적인 리포지토리를 개발 리포지토리 와 분리 합니다. 안정적인 저장소로 푸시하기 전에 코드를 검토해야합니다. 이는 안정적인 리포지토리에 현재 프로덕션에서 실행중인 코드가 포함되어 있어야하며 보류중인 코드 승격에 따라 다릅니다.

코드 검토를 시행하기 pretxnchangegroup위해 HG Book에 문서화 된 후크를 작성했습니다 . 이 후크가 실행될 때 코드 변경이 영구적 일 경우 리포지토리를 볼 수 있지만 푸시를 방지 할 수 있다는 사실을 이용합니다. 기본적으로 프로세스는 다음과 같습니다.

개발자는 안정적인 저장소로 푸시를 시작합니다 (예, 이것이 첫 번째 단계입니다)
후크는 HG 로그를 실행하여 트랜잭션에 포함 된 모든 변경 세트 목록을 실행하고 가져옵니다. 그런 다음 변경 내용이 코드 검토에 포함되었는지 확인하기 위해 구축 한 데이터베이스를 쿼리합니다. (표는 코드 검토 ID가있는 변경 세트의 해시와 일치합니다).
- 이러한 변경 세트가 처음으로 발견 된 경우, Code Collaborator 명령 행을 사용하여 새 코드 검토를 작성한 다음 해당 코드 세트의 ID를 사용하여 이러한 변경 세트를 데이터베이스에 기록합니다.
- 변경 세트 중 일부 (전부는 아님)를 확인한 경우 (Code Collaborator) 명령을 실행하여 새 변경 세트를 기존 검토에 첨부하고이 새 변경 세트를 데이터베이스에 기록합니다.
- 데이터베이스에서 모든 변경 사항이 발견되면 (즉, 모두 코드 검토에 추가 된 경우) 코드 검토 상태가 완료인지 확인합니다. 그러나 새로운 변경 세트가 있거나 코드 검토가 완료되지 않은 경우 후크는 0이 아닌 상태 코드로 종료되며 (Mercurial이 트랜잭션을 롤백하도록 함) 개발자에게 설명하는 표준 오류에 대한 친숙한 메시지를 출력합니다 코드 검토를 완료해야합니다.

본질적으로 이것은 개발자에게 매우 능률적 인 프로세스를 제공하고 (그들이해야 할 일은 hg 푸시뿐입니다) 모든 코드가 검토되도록하는 동시에 코드 검토 생성 (및 추가 변경 파일을 검토에 업로드)을 완전히 자동화합니다. .

참고 : 이것은 매우 간단한 프로세스이며 상대적으로 새로운 프로세스이므로 모든 사람에게 적용되지 않을 수 있으며 아직 실행하지 않은 디자인 버그가있을 수 있습니다. 그러나 지금까지는 아주 훌륭하게 작동했습니다.

— 라이언
소스

코드 검토 전에 안정적인 환경을 확인하기로 한 결정을 설명 하시겠습니까? 나에게 안정은 잘못된 것으로 보인다.

— Jordan

아마도 대답에서 명확하지 않았지만 모든 변경 사항이 코드 검토에 추가되고 검토가 완료되지 않으면 실제로 저장소에 저장되지 않습니다. 후크가 0이 아닌 종료 코드로 종료되면 Mercurial은 푸시 된 모든 변경 사항을 롤백합니다. 따라서 해당 후크는 검토를위한 차이점을 얻을뿐만 아니라 변경 사항이 저장소에 허용되기 전에 검토를 시행 할 수있는 매우 편리한 위치를 제공합니다.

— Ryan

와. 내가 당신을 위해 일할 수 있습니까?

— Rich

@Ryan-pretxnchangegroup 후크를 어떻게 구현합니까? 제공하는 링크는 구현 방법에 대한 자세한 설명을 제공하지 않으며 따라야 할 함수 템플릿의 종류를 제공하지 않습니다. 나는 파이썬 경험이 없다. pretxnchangegroup hook의 올바른 소스 또는 템플릿으로 나를 리디렉션 할 수 있습니까? Ta

— 간단한 솔루션

리포지토리 구조와 수행하려는 대상에 따라 다릅니다. 우리는 "사전 커밋"검토를 선호합니다. DVCS 세계에서는 실제로 "사전 푸시"를 의미합니다. DVCS는 기존의 SCM과 비교할 때이 환경에서 더 좋습니다. 로컬 변경 사항을 저장하고 작업 공간을 다시 가져 와서 다른 작업을 수행 할 수있는 기능이 내장되어 있기 때문입니다.

푸시 후 검토를 수행하려는 경우 이상적인 워크 플로우는 저장소 구조에 따라 크게 다릅니다. 예를 들어, Git 저장소 레이아웃 에 대해이 기사에서 설명한 것과 같은 저장소 구조를 가정 해 봅시다 . 이 경우에 통합되는 변경 사항을 검토 할 수 있습니다 develop. 기능 분기에 대한 개별 커밋은 검토하기에 적합하지 않을 수 있습니다. 분명히 모든 hotfixes합병과 함께 검토해야합니다 master.

대신 사람들이 직접 체크인하는 단일 통합 지점이있는 경우 해당 지점에 대한 모든 푸시를 검토하려고합니다. 아마 약간 덜 효율적이지만 여전히 작동 할 수 있습니다. 이 환경에서는 릴리스를 잘라 내기 전에 푸시 된 모든 변경 사항을 검토해야합니다. 더 까다로울 수 있습니다.

b) 내가 제안하는 유일한 것은 SmartBear 지원 (support@smartbear.com)에게 직접 이메일을 보내는 것입니다. 경로 문제를 해결하는 데 도움을 드리겠습니다 (예, SmartBear에서 근무 함).이 질문에 문제를 해결하기에 충분한 정보가 없습니다. 정상적인 과정은 설치 프로그램을 실행하는 것이며 모든 것이 제대로 작동합니다. 분명히 그 과정에서 무언가가 잘못되었습니다.

— 브랜든 듀엣
소스