あいさつ

Habrアーカイブを検索したところ、Perforce Helixについてはほとんど何も書かれておらず、RuNetにはVSの拡張と古い英語の記事Dear Perforce：fcuk youの翻訳 に関するレビュー記事しかありません 。 同時に、使用されているバージョン管理システムに関する記事へのコメントで、Perforceがよく言及されていたので、Perforce Helix機能に関する概要記事をいくつか公開したいと思いました。

免責事項 ：私はプロの開発者ではないので、実際の製品でHelixを使用しませんでした。 この記事を書くために、私は20人のユーザー向けの無料版であるドキュメンテーションを使用し、また小さなオープンソースプロジェクトを開発する際に生徒の一部がHelixを使用することを提案しました。 この記事と後続の記事の目的は、プラットフォームに関する情報源となることですので、コメントにご参加ください。

用語を理解します

Perforce、Helix、p4、p4d-Perforce Software（以下、Perforce）が20年以上にわたって行ってきたことの名前をいくつか見つけることができます。 この段落では、Perforce（今日）からのプロジェクト管理用プラットフォームのコンポーネントの名前で現状を修正したいと思います。

p4d（Helix Versioning Engine）-バージョン管理用のPerforceエンジン、
p4-p4dを操作するためのCLI、
p4v-p4dを操作するためのGUIクライアント、

Helixは、以下を含むPerforceの単一プラットフォームです。
1-バージョン管理用のコンポーネント（p4d、p4、p4v、ID​​Eから作業するためのプラグイン）、
2-コードレビュー用のHelix Swarmコンポーネント、
3-完了した作業、プロジェクトのステータス、チームのパフォーマンス、バグ修正の分析のためのHelix Insightsコンポーネント。
4-GitLabに基づくGitSwarmコンポーネント。Swarmと組み合わせて通常のgitワークフローで作業し、p4dを活用できます。

Helixにはクライアントサーバーアーキテクチャがあり、次のもので構成されています。
-ユーザーにリポジトリ（Helixの用語ではデポ）を提供し、ファイルの操作に関する情報、エンジン構成、ユーザーアクティビティログなどのデータベースをサポートするp4dエンジンを備えたサーバー
-p4、p4v、ID​​Eから作業するためのプラグイン。
以下に、Helixワークフローを定義する概念、チェンジリスト、シェルフ、ストリーム、ジョブ、ラベルについて説明します。

チェンジリストの棚

リポジトリへの送信は、チェンジリストの番号付きの値によって一意に決定されます。 チェンジリストには、少なくとも1つのファイルに対する変更が含まれている必要があり、数千のファイルに対する変更が含まれている場合があります。 ここではトランザクションが保証されているため、10個のファイルへの変更の送信中にp4dとクライアント間の接続が切断された場合、変更はリポジトリに移動しません。 各ファイルの現在のバージョンにも番号が付けられ、変更のたびに増分されます。

送信する前にレビューに変更を送信する場合は、シェルビング機能を使用できます。これにより、変更されたファイルのコピーを一時共有リポジトリ（shelveの「シェルフ」）に送信できます。

ストリーム

ストリームはHelixのブランチです。違いは、ストリームモデルには、ストリームを操作する際のアクションの可能性とシーケンスに関する情報が含まれていることです。
ストリームを作成するとき、そのタイプ、関連ファイル、および親ストリームを決定します。 ストリームを切り替えると、ワークスペースのスライスが自動的に変更されます。
おなじみの分岐モデルを見てみましょうが、その上で分岐を操作するロジックを表示します。



機能を開発するためにブランチが作成されたとします（プロジェクトY）。 正常に開発およびテストされた後、この機能をプロジェクトに実装する必要があります。 ただし、機能の開発中にMainline（マスターブランチ）が変更されたため、マージする前に、Project YがMainlineの現在の変更と一致していることを確認する必要があります。

p4vには、この情報を表示する便利なツールが含まれています。



より安定したストリームはメインラインより高く、不安定なストリームは低くなります。
Helixの用語には、2種類の分岐操作があります。
1-マージダウン、
2-コピーアップ。

ストリームの操作の基本原則：安定性の低いストリームBで行われた変更を安定性の高いAに追加する前に（コピーアップB、A）、安定性の高いストリームAのすべての変更を安定性の低いBに追加する必要があります（マージダウン） A、B）。



次のアイコンは、変更を親ストリームにコピーする前に、親ストリームから更新する必要があることを意味します。
ストリームを使用すると分岐が自動化されますが、誰もが使い慣れたブランチを使用できます。

ジョブ、ラベル

チェンジリストとストリームの使用に加えて、Helixには作業を整理するための追加の方法が含まれています。
1-ジョブはチェンジリストに添付され、バグに関する作業のステータスを表示します。 サードパーティのバグトラッカーと簡単に統合でき、管理者が設定します。作成者と依存バグを表示できるだけでなく、他のフィールドも追加できます。
2-ラベルはファイルリビジョンに関連付けられており、ラベルをグループにまとめることができます。 チェンジリストが1つのリビジョンのファイルのリストを定義している場合、ローブは異なるリビジョンのファイルのグループに属することができます。 リリースやビルドの成功に関連してファイルを結合したり、重要なプロジェクトコンポーネントをマークしたりする場合などに役立ちます。

Helixのコンポーネントと機能の一部

Helixは、大規模プロジェクトおよび分散チーム向けに特別に設計されたヘビー級の専用ハード通貨であるため、このために必要な多くの機能とサポートされる機能を備えています。

柔軟なHelixサーバーの構成メカニズム

永遠の契約（スケーラビリティ、復元力、パフォーマンス）を満たすため、Helixはさまざまなサーバー構成をサポートしています。
-接続チャネルの帯域幅が制限されている場合、 プロキシが使用されます。 プロキシは、個々のファイルへの頻繁なヒットを追跡することにより、サーバーへの直接のヒット数を減らし、ネットワークトラフィックのバランスを取ります。



- サーバーブローカーは、クライアントポリシーを使用して、着信呼び出しの負荷を分散します。
- サーバーレプリカは、メインサーバーの最もホットな（またはすべての）データをミラーリングします。

サーバーのタイプはその構成によって決定され、管理者が構成できます。 サーバーを柔軟に構成できるため、特にチームのニーズに合わせてサーバーを強化することにより、エンジンのパフォーマンスを最大化できます。 例は、コミットエッジアーキテクチャです。



-コミットサーバーはプロジェクトデータとメタデータを保存します
-エッジサーバーは、コミットサーバーのレプリカであり、それらにアクセスするユーザーのワークスペースのコピーです。 このようなサーバーは、読み取り専用操作のみを処理し、ユーザーのユーザー空間にあるファイルのみの上書き操作を処理します。
このアーキテクチャにより、中央コミットサーバーの負荷が軽減され、パフォーマンスが向上します。

Insights Analytics

Helixのコンポーネントの1つは、プロジェクトのステータス、コード、チームのパフォーマンスに関する重要な情報を表示するInsightsツールです。 Insightsは、このような情報をグラフィカルに表示します。 メトリックは完全に異なり、さらに、APIを使用してカスタマイズされます。

集中化および分散化されたアプローチ、GitSwarmのサポート

Helixは両方のパラダイムをサポートしています。
集中型のアプローチの場合、ユーザーはp4dサーバーで直接作業します。 ワークスペース内のリポジトリのスライスは、ユーザーが操作できるファイルを定義します。



すべてがよく知られているので、追加のコメントは不要です。 分散型アプローチでは、従来の原則も尊重されます。



Helixの興味深い機能はハイブリッドアプローチであり、さまざまなユーザーがサーバーに直接接続するか、独自のローカルサーバーを使用して、プッシュを介して中央リポジトリと通信できるようにします。

Gitに慣れているが、上記のp4dの利点と機能を活用したい開発者向けに、バックエンドとしてp4dを使用するGitFusionサービスとチームインタラクションおよびプロジェクト管理用のWebインターフェイスを含むGitSwarmコンポーネントがあります。



私の意見では、これは本当にクールです。別のハード通貨への切り替えは常に苦痛なプロセスであり、Helixを使用すると、エンジンを介してすべての操作を実行しながら、すべてのお気に入りのgitを維持できます。

この部分の要約

そのため、このパートでは、Helixシステムのコンポーネントの概要を説明し、ワークフローp4dを定義する概念を示し、システムの機能の一部について説明します。
このパートで表現したかった主なアイデアは次のとおりです。Perforceには、スケーラブルでフォールトトレラントな非常に強力なp4dエンジンがあり、gitワークフローと簡単に統合できますが、p4コマンドライン、p4vクライアント、またはIDEのプラグインでも機能します。 したがって、Gitを介して何かが機能しない（または難しい）場合、p4dに簡単に切り替えることができます。
プラットフォーム自体は非常に機能的であるため、将来は各コンポーネントを個別に見て、それらの作業の原理をより詳細に説明したいと思います。
Helixの経験がある読者に経験を共有してもらいたい。