GitHub와 GitLab 엔지니어링 측정항목: 무엇을 비교할 수 있나요?
검토, 계획 및 ID 개념이 동일한 것처럼 가장하지 않고 공급자 간에 공유 제공 모델을 구축합니다.
공통 전달 수명주기 표준화
GitHub 풀 요청 및 GitLab 병합 요청은 리포지토리, 작성자, 상태, 생성 시간, 병합 시간, 대상 브랜치, 레이블, 담당자, 요청된 검토자, 커밋 및 공급자 URL과 같은 유용한 핵심을 공유합니다. 정규화된 모델은 두 공급자 모두에서 공개 작업, 병합 시간, 처리량, 오래된 변경, 기여자 참여 및 저장소 활동을 지원할 수 있습니다. 사용자가 소스를 열 수 있도록 모든 행에 공급자 및 공급자 레코드 ID를 유지하고 반복된 동기화로 중복을 생성하는 대신 올바른 레코드를 업데이트합니다.
차이점을 납작하게 만드는 대신 보존하세요.
공급자는 승인 규칙, 검토자 할당, 초안 동작, 이벤트 API, 프로젝트 계층 구조, 레이블, 마일스톤, 반복 및 그룹이나 조직 전체에서 ID가 표시되는 방식이 다릅니다. 없는 필드는 자동으로 0이 되지 않습니다. 동등한 의미를 갖는 것을 정규화하고 나머지에 대해서는 공급자별 메타데이터를 유지합니다. 인터페이스는 사용자가 기록을 검사할 때 원래 용어와 링크를 표시하는 동시에 변경, 풀 및 병합 요청 등 가능한 경우 공급자 중립적 언어를 사용해야 합니다.
리뷰 지표를 적용 범위에 민감한 것으로 취급
변경 사항으로 인해 완료된 검토 이벤트, 봇의 댓글, 나중에 취소된 승인 또는 API 전체에 명확하게 매핑되지 않는 토론 이벤트 없이 검토자를 요청할 수 있습니다. 변경이 준비된 후 첫 번째 검토를 의미 있는 인적 검토로 정의한 다음 사용된 증거와 이벤트 유형을 기록합니다. 알려진 봇을 지속적으로 제외합니다. 측정 가능한 검토 데이터가 있는 변경 사항 수를 게시합니다. 비교 가능한 이벤트 적용 범위 없이 공급자 중앙값을 비교하면 정확해 보이지만 잘못된 결론이 나올 수 있습니다.
계획 개념을 의도적으로 매핑
GitLab 반복은 종종 케이던스 그룹에 속하며 날짜가 지정된 전달 기간을 나타냅니다. 마일스톤은 별도의 개념이며 릴리스 또는 더 광범위한 목표를 설명할 수 있습니다. GitHub 마일스톤은 계획 창을 제공할 수 있는 반면, 스프린트와 유사한 동작은 프로젝트 또는 레이블에 있을 수 있습니다. 모든 마일스톤의 이름을 반복으로 바꾸거나 날짜에서 팀을 추론하지 마세요. 공급자 유형, 제목, 날짜, 상위 케이던스 또는 프로젝트, 소스 URL을 저장합니다. 개념이 다양한 관리 질문을 지원하는 경우 별도의 필터를 제공합니다.
제공자 기능 수가 아닌 결정 비교
공급업체 간 보고는 다음과 같은 공유 질문에 답할 때 가장 유용합니다. 리뷰 대기가 증가하는 곳은 어디입니까? 어떤 작업 흐름이 이동하고 있나요? 소유권이 어디에 집중되어 있나요? 비교하기 전에 동일한 기간, 저장소 범위, 봇 정책 및 ID 일치를 적용하십시오. 각 제공업체의 적용 범위를 표시하고 사용자가 소스를 자세히 살펴볼 수 있도록 합니다. 목표는 하나의 플랫폼을 더 빠르게 선언하는 것이 아닙니다. 이는 증거를 신뢰할 수 있게 만드는 의미론을 존중하면서 다중 제공자 조직에 하나의 일관된 관점을 제공하는 것입니다.