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

• 우리는 모든 저장소의 중앙 결정 사본을 하나의 서버에 보관합니다. 개발자가 코드를 “체크 아웃”하려고 할 때이 서버로 이동하여 리포지토리에서 복제합니다. 마찬가지로 개발주기가 완료되면 코드가 해당 저장소로 푸시됩니다.

• 안정적인 리포지토리를 개발 리포지토리 와 분리 합니다. 안정적인 저장소로 푸시하기 전에 코드를 검토해야합니다. 이는 안정적인 리포지토리에 현재 프로덕션에서 실행중인 코드가 포함되어 있어야하며 보류중인 코드 승격에 따라 다릅니다.

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

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

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

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

답변