GitHub と GitLab のエンジニアリング指標: 何を比較できますか?
プロバイダー間のレビュー、計画、アイデンティティの概念が同一であるかのように装うことなく、プロバイダー間で共有される配信モデルを構築します。
共通の配信ライフサイクルを正規化する
GitHub プル リクエストと GitLab マージ リクエストは、リポジトリ、作成者、状態、作成時間、マージ時間、ターゲット ブランチ、ラベル、担当者、要求されたレビュー担当者、コミット、プロバイダー URL といった有用なコアを共有します。正規化されたモデルは、オープンな作業、マージまでの時間、スループット、古い変更、共同作成者の参加、および両方のプロバイダーにわたるリポジトリ アクティビティをサポートできます。すべての行にプロバイダーとプロバイダー レコード ID を保持すると、ユーザーがソースを開くことができるようになり、同期を繰り返すことで重複が作成されるのではなく、正しいレコードが更新されます。
差異を平坦化するのではなく維持する
プロバイダーは、承認ルール、レビュー担当者の割り当て、ドラフト動作、イベント API、プロジェクト階層、ラベル、マイルストーン、イテレーション、およびグループまたは組織間での ID の表示方法が異なります。存在しないフィールドは自動的にゼロにはなりません。同等の意味を持つものを正規化し、残りについてはプロバイダー固有のメタデータを保持します。インターフェイスでは、ユーザーがレコードを検査するときに元の用語とリンクを表示しながら、変更やプルおよびマージ リクエストなど、可能な限りプロバイダーに依存しない言語を使用する必要があります。
レビュー指標をカバレッジに依存するものとして扱う
変更により、完了したレビュー イベント、ボットからのコメント、後で却下された承認、または API 全体に適切にマッピングされていないディスカッション イベントのないレビュー担当者が要求された可能性があります。変更の準備ができた後、最初のレビューを有意義な人によるレビューとして定義し、使用した証拠とイベントの種類を記録します。既知のボットを一貫して除外します。測定可能なレビュー データが含まれる変更の数を公開します。比較可能なイベント カバレッジを持たずにプロバイダーの中央値を比較すると、正確に見えても誤った結論が得られる可能性があります。
計画の概念を慎重にマッピングする
GitLab のイテレーションは多くの場合、ケイデンス グループに属し、日付付きの配信ウィンドウを表します。マイルストーンは別の概念であり、リリースまたはより広範な目標を表す場合があります。 GitHub マイルストーンは計画ウィンドウを提供できますが、スプリントのような動作はプロジェクトまたはラベルに存在する場合があります。すべてのマイルストーンの名前を反復として変更したり、日付からチームを推測したりしないでください。プロバイダーのタイプ、タイトル、日付、親のケイデンスまたはプロジェクト、およびソース URL を保存します。コンセプトがさまざまな管理上の質問をサポートする場合は、個別のフィルターを提供します。
プロバイダーの機能数ではなく、決定を比較する
プロバイダー間のレポートは、「レビュー待ちが増加しているのはどこですか?」という共通の質問に答える場合に最も役立ちます。どのワークストリームが移行しているのでしょうか?所有権はどこに集中していますか?比較する前に、同じ時間枠、リポジトリ スコープ、ボット ポリシー、および ID の一致を適用します。各プロバイダーの対象範囲を表示し、ユーザーがソースをドリルダウンできるようにします。目標は、1 つのプラットフォームをより速く宣言することではありません。それは、証拠を信頼できるものにするセマンティクスを尊重しながら、マルチプロバイダー組織に 1 つの一貫したビューを提供することです。