ツイートはてブ LINE Pocket

ブランチ: Space Git フロー

チームにとって適切な分岐戦略を選択することは、コード変更の導入の安全性、新機能のリリース頻度、変更を実稼働環境にどれだけ早く配信できるかなど、開発プロセスに重大な影響を与える可能性があるため重要です。

一般的な戦略には次のようなものがあります。

Git の流れ

この戦略は、明確なリリースプロセスがあり、実稼働環境を安定に保つ必要があるチームに役立ちます。

main ブランチは製品コード専用です。
develop ブランチは開発コード用です。
feature ブランチは開発したブランチから作成されます。
release および hotfix ブランチは、main ブランチから作成されます。

GitHub の流れ

この戦略は、コラボレーション、頻繁なリリース、合理化された開発プロセスに重点を置いています。

main ブランチは製品コード専用です。
開発は個別の feature ブランチで行われ、準備ができたら main ブランチにマージされます。
プルリクエストは、コードレビューとマージ前の変更についての議論に使用されます。
リリースは main ブランチから切り取られ、簡単にバージョン管理できるようにタグが付けられています。

トランクベースの開発

この戦略では、安定したトランクブランチを維持するために、開発者間の厳格な規律と協力が必要です。

すべてのコードは、通常 trunk と呼ばれる単一のブランチにコミットされます。
トランクブランチは常に実稼働準備が整っています。
開発作業は trunk ブランチ上で直接行われます。
長命の feature ブランチはありません。
変更をプッシュする前に、開発者はローカルマシン上で完全な「統合前」ビルド (コンパイル、単体テストなど) を実行します。
変更がすでに trunk に反映された後、「統合後」のコードレビューが行われる可能性があります。

各戦略には独自の長所と短所があり、最適な選択はチームの特定のニーズによって異なります。Space ではほぼすべてのフローを実装できますが、Space 固有の戦略 (Space Git フロー) の採用を検討することをお勧めします。

Space Git の流れ

Space Git フローは GitHub フローに似ていますが、main ブランチへの変更の安全性と、大規模なプロジェクトやチームへの拡張性に重点が置かれています。JetBrains では、JetBrains Space 自体を含む多くの製品にこのフローを使用しています。

Space Git フローの主な概念は以下のとおりです。これらをやるべきことリストとして検討してください。ほとんどの項目はオプションですが、取得すればするほど、可能な限り最良かつ最も安全なフローに近づくことになります。

保護されたブランチ

単一の main ブランチは常に実稼働可能です。main ブランチは保護されており、直接コミットは許可されません。

ブランチを保護する方法を学ぶ

ブランチ機能とマージリクエスト

feature ブランチを作成するときは、常に最新の main から、または必要に応じて別のフィーチャーブランチからこれを実行します。feature ブランチから main への変更をマージするには、マージリクエストを作成する必要があります。

マージリクエストとクオリティゲート

変更を実際にマージするには、マージリクエストが品質ゲート (一連の条件) を通過する必要があります。品質ゲートは 3 つあります。それぞれはオプションです。

ターンベースのコードレビューでの承認 : 変更についてコメントした後、レビュー担当者は作成者に順番を渡します。次に、作成者はコメントとフィードバックをコードに適用し、必要な修正を加えます。リビジョンが作成されると、作成者はコードレビューに新しいコミットを追加し、レビュー担当者にターンを返します。このプロセスは、レビューが最終的にレビュー担当者によって承認されるまで続きます。
レビュー担当者は、コード所有者機能に基づいて自動的に割り当てることができます。CODEOWNERS ファイルは、リポジトリ内の特定のパスまたはファイルの所有者を概説します。
コード所有者の設定方法を学ぶ
Space オートメーションジョブが正常に完了しました。
外部チェック。外部サービスが HTTP API リクエストを Space に送信してマージリクエストを承認した場合に合格します。例: これは、JetBrains TeamCity のような外部 CI/CD サービスである可能性があります。
「グリーンビルド」品質のゲートを設定する方法を学ぶ

安全なマージ

安全なマージは、feature ブランチから main への変更を最終的にマージする前の追加の安全手順です。マージリクエストの変更に基づいて、Space は main と feature ブランチの両方からの最新の変更を含む一時的なマージコミットを作成します。このコミットには独自の ref があり、必要な品質チェック (プロジェクトをコンパイルしてテストを実行するオートメーションジョブや TeamCity ビルドなど) を実行するために使用できます。チェックが成功すると、feature からの変更が最終的に main にマージされます。

「グリーンビルド」品質ゲートの代わりに、またはそれに加えて、安全なマージを使用できます。安全なマージを設定する方法を学ぶ

リリースブランチ

プロジェクトにパブリックリリースが含まれる場合は、最新の main から作成された release ブランチを使用する必要があります。必要に応じて、直前の変更が main から特定の release ブランチに厳選されます。

プロジェクトにおける Space Git フローの仕組み

こちらは、Space Git フローを完全に実装したプロジェクトのショーケースです。

チュートリアル: プロジェクトの Space Git フローをセットアップする

Space Git フローの最も良い点は、現在 JetBrains Space を使用していない場合でも、既存のプロジェクトに簡単に採用できることです。

仮定する:

GitHub (または別の Git ホスティング) でホストされているプロジェクトがあります。
(オプション) CI/CD の目的で JetBrains TeamCity を使用します。

Space Git フローに切り替える方法は次のとおりです。

ステップ 1. Space 組織を作成する

まず最初に – Space に新しい組織を作成することから始めます。

JetBrains Space ページに移動し、無料でお試しくださいをクリックします。
プロファイルと組織の設定を入力します。最も重要なものは、将来の Space インスタンスの URL です。通常、会社またはチームの名前が含まれます。このチュートリアルでは、acme-corp.jetbrains.space になります。
ブラウザーで Space インスタンスを開きます。
Space Git フロー機能の一部には、少なくとも組織プランが必要です。30 日間の試用期間中は無料でお試しいただけます。組織プランに切り替えるには:
1. メインメニューで、管理をクリックします (この項目が表示されない場合はメニューを展開します)。
2. 請求とプランを選択します。
3. 定期購入プランで、プレミアム機能を試すをクリックします。
  試用版ライセンスの有効化には時間がかかる場合があります。
4. 確認をクリックします。

終わり ! 組織プラン機能が有効になっている作業 Space インスタンスがあります。

ステップ 2. 既存の Git リポジトリをミラーリングする

このチュートリアルでは、既存の Git リポジトリがどこかにホストされていると仮定します。実際には、これは任意の Git ホスティングでかまいませんが、簡単にするために GitHub とします。ここでのゴールは、Space にそのミラーを作成することです。

プロジェクトのサイドバーで、リポジトリを選択します。
新規リポジトリをクリックします。
新規リポジトリウィンドウで:
1. GitHub ミラーを選択します。
2. GitHub リポジトリ URL を指定してください。
3. 「新しいトークンを取得する」をクリックして、GitHub からアクセストークンを取得します。トークンを取得したら、テキストフィールドに貼り付けます。
作成をクリックします。
重要 ! すべての開発者が新しい Git リモート (Space のミラー) に切り替えたことを確認します。そうしないと、以降の手順で適用するすべてのリポジトリ制限が意味をなさないことになります。

終わり ! Space にはリポジトリの動作するミラーがあります。Space ミラーにプッシュしたコミットは GitHub リポジトリに配信され、その逆も同様です。

ステップ 3. メインブランチを保護する

次のステップは、main ブランチを直接コミットから保護することです。これを実行した後、main に変更を加えることができる唯一の方法は、マージリクエストを介することです。

プロジェクトのサイドバーで、リポジトリを選択します。
リポジトリを選択し、その設定を開きます。
「保護されたブランチ」タブを開き、「新規ルール」をクリックします。
新しいブランチ保護ルールウィンドウで:
1. +:main をブランチの名前パターンに追加します。これは、Space がどのブランチにルールを適用する必要があるかを決定できるパターンです。
2. プッシュと規制された行為の強制プッシュが誰でもないに設定されていることを確認します。
保存をクリックします。

終わり ! 誰もプロジェクトの main ブランチにコミットをプッシュしたり、強制的にプッシュしたりすることはできません。現時点で main にプッシュする唯一の方法は、マージリクエストを使用することです。

ステップ 4. 必須のコードレビューとコード所有者を追加する

コードの品質を確保する主な方法の 1 つは、マージリクエストを導入することです。開発者は、変更を保護されたブランチにマージする明示的なリクエストを作成する必要があります。マージされる前に、変更はいわゆる品質ゲートを通過する必要があります。このチュートリアルで設定する最初の品質ゲートは、必須のコードレビューです。コードの変更を main にマージする前に、同僚がコードの変更をレビューして承認する必要があります。

コードレビューに適切な担当者の割り当てを簡素化するために、コード所有者機能を使用できます。これは、特定のファイルとディレクトリを対応するチームメンバーに割り当てる CODEOWNERS ファイルです。コードレビューが作成されると、Space は CODEOWNERS に基づいてレビュー担当者を自動的に割り当てます。

コードレビュー品質ゲートを追加するには

Space インスタンスを開き、プロジェクトのサイドバーでリポジトリを選択します。
リポジトリを選択し、その設定を開きます。
保護されたブランチタブを開き、以前に作成したルールを編集します。
マージリクエストの品質ゲートで、スイッチオンをオンにします。
要件で承認を開き、必要なレビュー担当者を From フィールドに指定します。これは特定のユーザーまたはユーザーグループである可能性があります。... の承認が必要ですフィールドに、必要な承認数を指定します。例:
- プロジェクトメンバーからの承認が 2 つ必要です : マージリクエストは、少なくとも 2 人のプロジェクトメンバー (任意のメンバー) によって承認される必要があります。
- プロジェクト管理者から、John Doe には 1 つの承認が必要です : マージリクエストは、John またはプロジェクト管理者のロールを持つユーザーによって承認される必要があります。

コード所有者を追加するには

プロジェクトリポジトリで、CODEOWNERS ファイルを作成します。ファイルはプロジェクトルートまたは .space ディレクトリに配置する必要があります。
重要 ! CODEOWNERS ファイルは、マージリクエストのターゲットブランチ上に存在する必要があります。main ブランチを保護する場合は、CODEOWNERS ファイルも main ブランチに配置する必要があります。
CODEOWNERS ファイルで、コードベースの特定の部分を特定のユーザーまたはユーザーグループに割り当てます。例:
# John handles Gradle files *.gradle John.Doe # Sarah handles the source code src Sarah.Connor # CODEOWNERS file is for Project Admins CODEOWNERS "Project Admin"
ファイル構文の詳細については、「コードの所有者」を参照してください。
リポジトリ設定で、保護されたブランチタブを開き、以前に作成したルールを編集します。
マージリクエストの品質ゲートがまだ有効になっていない場合は、オンにします。
要件で、承認を開き、コード所有者の承認を必要とするチェックボックスを選択します。

終わり ! 今後は、マージリクエストには必須のコードレビューが必要になります。

重要: From フィールドを使用して追加したレビュー担当者と、CODEOWNERS ファイルに基づいて割り当てられたレビュー担当者は、除外するものではなく、相互に補完します。From および CODEOWNERS で指定されたすべてのレビュー担当者の承認が必要です。

ステップ 5. CI/CD サーバーを Space に接続する

CI/CD は JetBrains TeamCity 経由でプロジェクト用にすでに構成されていると仮定します。そうでない場合は、Space – Space Automation に組み込まれた CI/CD サーバーを構成できます。このチュートリアルでは、TeamCity とオートメーションの両方の手順を説明します。

Space Automation を使用する場合は、この手順をスキップしてください (単にスキップするのではなく、例に従ってプロジェクトのオートメーションを構成することをお勧めします)。

まず、TeamCity が Space にログインできるように認証トークンを取得する必要があります。トークンを取得するには、Space にアプリケーションを登録する必要があります。TeamCity は、このアプリケーションに代わって Space で動作します。
1. メインメニューで、拡張、新しいアプリの順にクリックします。
2. アプリケーション名を指定します。例: TeamCity をクリックし、作成をクリックします。
3. アプリケーション設定、つまり許可タブに移動します。
4. コンテキスト内認証で、プロジェクトで承認をクリックします。
5. プロジェクト (この場合は acme-corp) を選択し、許可をクリックします。
6. 構成をクリックし、次の権限を選択します。
  - プロジェクト | プロジェクトの詳細を表示
  - Git リポジトリ | 外部ステータスチェックのレポート
  - Git リポジトリ | Git リポジトリの読み込み
  - コードレビュー | コードレビューを見る
7. 保存をクリックします。
8. 許可タブに戻り、グローバル認証の構成をクリックします。ここでは、メンバー | メンバープロファイルを見る権限が必要です (これにより、TeamCity はビルドを開始するユーザーに関する情報を取得できるようになります)。保存をクリックします。
次に、TeamCity が Space で認証する方法を構成しましょう。
1. アプリケーション設定で、認証タブに切り替えます。
2. 認証フローで認証コードフローを有効にし、保存をクリックします。TeamCity サーバーのリダイレクト URI https://<server>:<port>/oauth/space/accessToken.html を入力します。例: TeamCity クラウドインスタンスが acme-corp の場合、URI は https://acme-corp.teamcity.com/oauth/space/accessToken.html になります。
3. クライアント ID とクライアントシークレットをコピーします。これらは、TeamCity が Space での認証に使用する資格情報です。
次に、TeamCity 側で接続を構成しましょう。
1. TeamCity インスタンスを開き、プロジェクト設定 | 接続に移動します。
2. 接続の追加をクリックし、JetBrains Space 接続タイプを選択します。
3. 接続設定を指定します。Space インスタンスの URL、および前の手順で取得したクライアント ID およびクライアントシークレットです。
ここで、TeamCity プロジェクトの VCS ルートを Space に変更する必要があります。
1. TeamCity インスタンスを開き、プロジェクト設定 | VCS のルートに移動します。
2. 現在の Git サーバーを指す VCS ルートの Edit をクリックします。
3. URL を取得で、Space アイコンをクリックし、Space インスタンスにサインインします。
4. Space アイコンをもう一度クリックし、Space で必要な Git リポジトリを選択します。
5. 新しい Git リポジトリ名に対応するように VCS ルート名を変更し、ID を再生成をクリックします。
6. ビルドを実行して、変更が正しいことを確認します。

終わり ! CI/CD サーバーは Space に接続されているため、「グリーンビルド」要件に使用する準備ができています。

ステップ 6. 「グリーンビルド」品質ゲートを追加する

コードの品質を保証するもう 1 つの品質ゲートは、「グリーンビルド」要件です。CI/CD サーバーがソースブランチ (変更を含むもの、たとえば feature ブランチ) を正常に構築できる場合にのみ、変更を main にマージできます。このステップでは、Space Automation と TeamCity の両方でこれを行う方法を示します。

プロジェクトを構築するオートメーションジョブがすでに作成されていることを意味します。そうでない場合は、これを実行する良い機会です。Space インスタンスを開き、プロジェクトのサイドバーでジョブを選択し、指示に従います。自動化の例をチェックすることを忘れないでください。
プロジェクトのサイドバーで、リポジトリを選択します。
リポジトリを選択し、その設定を開きます。
保護されたブランチタブを開き、以前に作成したルールを編集します。
マージリクエストの品質ゲートがまだ有効になっていない場合は、オンにします。
要件でジョブを開き、オートメーションジョブを選択します。

まず、TeamCity がビルドステータスを Space に報告できるようにするビルド機能を追加する必要があります。
1. TeamCity インスタンスを開き、ビルド設定 | 機能を構築するに移動します。
2. ビルド機能を追加をクリックし、ステータス発行者のコミットを選択します。
3. 設定を指定します: Space VCS ルート、JetBrains Space を出版社、および Space への接続。保存をクリックします。
4. ビルドを実行して、初めてビルドステータスを Space に送信します。これは、プロジェクトに対応する TeamCity ビルドがあることを Space が理解できるようにするためです。
Space インスタンスを開き、プロジェクトのサイドバーでリポジトリを選択します。
リポジトリを選択し、その設定を開きます。
保護されたブランチタブを開き、以前に作成したルールを編集します。
マージリクエストの品質ゲートがまだ有効になっていない場合は、オンにします。
要件で外部チェックを開き、TeamCity ビルドを選択します。

終わり ! この手順を完了すると、対応する CI/CD ビルドが正常に完了するまで変更をマージできなくなります。

ステップ 7. 「安全なマージ」を設定する

多数のマージリクエストがあるプロジェクトでは、単純な「グリーンビルド」品質ゲートよりも安全なマージ機能を優先するのが理にかなっています。安全なマージでは、main および feature ブランチからの最新の更新を含む一時的なマージコミットを作成し、オートメーションジョブまたは TeamCity ビルドでテストします。feature ブランチで作業している間に、main ブランチが作業と競合する変更を受け取った可能性があるため、これは重要です。安全なマージを使用すると、実際にブランチをマージする前にこれらの競合を検出できます。

まずは、安全なマージ設定を構成する JSON ファイルの作成から始めましょう。ファイルの正確な場所は関係ありません。主な要件は、ターゲットリポジトリにファイルを作成する必要があることです。この例では、main です。
ファイルを作成し、その内容を編集します。この例では、安全なマージ中に実行する必要があるオートメーションジョブを指定する単純な構成が必要です。
// If you want to use this example in a real JSON file, delete all comments first! { // Safe Merge version number. Should be "1.0" "version": "1.0", // What to do it build fails. // This setting is helpful for builds with flaky tests. "retry-policy": { // How many build attempts are allowed "num-retries": 3, // Use the same temporary merge commit on a retry // or create a new one "reuse-merge": true }, "builds": [ { "job": { // Automation job name "name": "Build and run tests" } } ] }
設定構文の詳細については、安全なマージのドキュメントを参照してください。
リポジトリ設定を開きます。
保護されたブランチタブを開き、以前に作成したルールを編集します。
安全なマージオンを回し、構成ファイルの選択をクリックします。
ファイルを選択し、保存をクリックします。

まず、新しいブランチ仕様を TeamCity のプロジェクトの VCS ルートに追加します。TeamCity はデフォルトで refs/heads/* ブランチのみを監視しますが、Space は refs/merge/<merge-request-name>/safe-merge に一時的なマージコミットを作成するため、これを行う必要があります。
1. TeamCity で、プロジェクト設定を開き、次に VCS のルートを開きます。
2. VCS ルートを編集します。つまり、ブランチ仕様に次の行を追加します。
  +:(refs/merge/*)
Space が TeamCity と通信できるようにするには、TeamCity アクセストークンを取得する必要があります。
1. TeamCity でプロファイルを開き、次にアクセストークン、次にアクセストークンの作成をクリックします。
2. 名前や有効期限などのトークンのオプションを指定します。セキュリティ上の理由から、プロジェクトごとに権限の範囲を制限し、次の権限を付与します。
  - ビルドの実行
  - 個人的なビルドを停止 / キューから削除
  - ビルドを停止 / キューから削除
  - ビルド構成設定を表示する
  - ビルドのランタイムパラメーターとデータを表示する
3. トークン値を安全な場所にコピーします。
TeamCity トークンを Space の秘密ストレージに保存します。
1. Space インスタンスを開き、次にプロジェクトを開きます。
2. プロジェクトのサイドバーで、設定を選択します。
3. シークレットとパラメータータブを開き、作成をクリックして、シークレットを選択します。
4. キーでは、シークレット名を指定します。teamcity-token この名前を使用して、安全なマージ構成でこのトークンを参照します。
5. 値に、前の手順のトークン値を貼り付けて、保存をクリックします。
すべての準備が完了したため、安全なマージを設定できるようになりました。
このプロジェクト用に TeamCity ビルドがすでに構成されていることを意味します。
次に、安全なマージ設定を構成する JSON ファイルを作成する必要があります。ファイルの正確な場所は関係ありません。主な要件は、ターゲットリポジトリにファイルを作成する必要があることです。この例では、main です。
ファイルを作成し、その内容を編集します。この例では、TeamCity サーバー設定と、安全なマージ中に実行する必要があるビルド構成を指定する単純な構成が必要です。
// If you want to use this example in a real JSON file, delete all comments first! { // Safe Merge version number. Should be "1.0" "version": "1.0", // What to do it build fails. // This setting is helpful for builds with flaky tests. "retry-policy": { // How many build attempts are allowed "num-retries": 3, // Use the same temporary merge commit on a retry // or create a new one "reuse-merge": true }, "builds": [ { "teamcity": { // Build configuration ID // You can get it in build config settings "configuration": "AcmeProject_BuildAndRunTests", // URL of your TeamCity instance "url": "https://acme-corp.teamcity.com", // Key of the secret that stores TeamCity token // Created in one of the previous steps // Format: ${secret-key} "token": "${teamcity-token}", } } ] }
設定構文の詳細については、安全なマージのドキュメントを参照してください。
リポジトリ設定を開きます。
保護されたブランチタブを開き、以前に作成したルールを編集します。
安全なマージオンを回し、構成ファイルの選択をクリックします。
ファイルを選択し、保存をクリックします。

以上です ! 安全なマージ機能がプロジェクトに対して有効になっています。これで、マージリクエストのマージボタンが安全なマージに変わります。これをクリックすると、一時的なマージコミットが作成され、JSON ファイルで指定した CI/CD ビルドが実行されます。ビルドが成功すると、最終的に変更が main ブランチにマージされます。実際に変更をマージせずにビルドのみを実行する場合は、「リハーサル」をクリックします。

結論

Space Git フローが大規模なプロジェクトやチームの課題に対処し、コードの変更がマージ前に徹底的にレビューおよびテストされることを保証すると信じています。ただし、このチュートリアルは出発点としては適していますが、プロジェクトごとに異なることは明らかであり、ニーズを完全に満たすためには最終的なフロー構成にいくつかの調整が必要な場合があります。

最終更新日: 2023 年 6 月 16 日

JetBrains Space ヘルプ