CI/CD のための Git Flow と Trunk-Based の選択 Git Flow Git Flow は、構造化されたバージョン管理環境に最適です。複数のブランチを使用し、主に master と develop です。大量のチーム、遅いリリースサイクル、厳格な QA プロセスに適しています。
- Trunk-Based DevelopmentTrunk-Based Development は、主に 1 つのメインブランチに短期間の機能ブランチを使用します。小規模のチーム、高速なリリース、強力な自動テストに適しています。
main,develop,feature,release比較の要点hotfix__CAPGO_KEEP_0__ - __CAPGO_KEEP_0____CAPGO_KEEP_0__
__CAPGO_KEEP_0__
| アスペクト | Git Flow | トランクベース開発 |
|---|---|---|
| ブランチ複雑さ | 長期間のブランチ | 短期間のブランチ |
| リリースサイクル | 定期リリース | 継続的デプロイ |
| チームサイズ | 大規模チーム | 小規模チーム |
| __CAPGO_KEEP_0__ | __CAPGO_KEEP_1__ | __CAPGO_KEEP_2__ |
| __CAPGO_KEEP_3__ | __CAPGO_KEEP_4__ | __CAPGO_KEEP_5__ |
| __CAPGO_KEEP_6__ | __CAPGO_KEEP_7__ | __CAPGO_KEEP_8__ |
__CAPGO_KEEP_9____CAPGO_KEEP_10__
__CAPGO_KEEP_11__
Git Flow ワークフロー基本
Git Flowは開発を5つのブランチタイプで組織する: main, develop, feature, release、 hotfix。この構造はリリースと並行開発を効果的に管理するのに役立ちます。
Git Flow Branch Structure
| Branch Type | 目的 | マージ先 |
|---|---|---|
| メイン | 生産用途のcodeを保持する | N/A |
| 開発 | 機能を統合し、機能ブランチのベースとして機能する | N/A |
| 機能 | 個々の機能を構築するために使用される;機能ブランチを作成するために開発から作成される | 開発 |
| リリース | __CAPGO_KEEP_0__ | main & develop |
| Hotfix | main & develop | Git Flowの利点 |
複数の機能を同時に開発できるようにし、コンフリクトを起こさないようにする。
- リリースブランチは、最終テストとバージョン準備のための専用スペースを提供し、開発ブランチを継続的な作業に開放する。
- develop リリース __CAPGO_KEEP_0__
- Hotfix __CAPGO_KEEP_0__
Git Flowの欠点
- Branch管理の複雑さ: 複数のアクティブなブランチを管理すると、マージが困難になることがあります。
- 遅れたデプロイ: 正式なリリースプロセスは、よりシンプルなワークフローと比較してデプロイを遅くする可能性があります。
- 増加したメンテナンス: 各ブランチには独自のパイプライン構成が必要になり、メンテナンス負荷が増加します。
このワークフローは、厳格なバージョン管理、複数のリリーストラック、または規制の遵守が必要なプロジェクトに最適です。次に、トランクベースの開発の流れについて詳しく説明します。
トランクベース開発の基本
トランクベース開発(TBD)は、主に1つのメインブランチ、通常はトランクまたはメインと呼ばれるものに焦点を当てています。このアプローチは、DevOpsの実践と継続的な統合に近いものです。
トランクベースブランチ構造
一般的なTBDワークフローでは、次のブランチタイプを遭遇することになります。
| ブランチタイプ | 目的 | 期間 |
|---|---|---|
| メイン/トランク | Central branch with production-ready code | 永久 |
| 機能ブランチ | 個々の変更用の短期間のブランチ | 短期間 |
| リリースブランチ | リリース前の最終調整用 | 一時的な |
開発者は、メインブランチに小さな、段階的な変更を頻繁にマージする。 これは、CI/CDとDevOpsを使用するチームにとって、継続的なテストと迅速な対処が可能になる。
トランクベースの利点
TBDは、CI/CDとDevOpsを使用するチームに以下の利点をもたらします。
- マージコンフリクトの少なさマージが頻繁に実行されるため、コンフリクトを管理することが容易になります。
- 迅速なフィードバックマージごとに自動ビルドが実行されるため、早期にバグを検出できます。
- シンプルなパイプラインメインブランチが単一のブランチであるため、CI/CDのセットアップの複雑さが減ります。
- チーム間のコラボレーションの向上全員が同調できるようにするには、共通の根幹となるものが必要です。
この構造は、Git Flow と比較するための基盤を整える、効率的なワークフローを構築します。
トランクベース制限
TBDには強みがあるが、チームはその課題を解決する必要がある。
| 課題 | 影響 | アドレスの指定方法 |
|---|---|---|
| Code 安定性 | メインの変更に影響するリスクのある変更 | 自動化テストを強化してください。 |
| チーム統合 | 重複した作業は混乱を引き起こすことがあります。 | 機能フラグと頻繁な小さなコミットに頼る |
| 学習曲線 | 長期間のブランチから移行する | トレーニングを提供し、段階的に導入する |
| 拡大問題 | 大規模チームでは頻繁なマージが混乱を招く | codeの徹底的な確認を強制する |
TBDの成功には、チーム内でオープンなコミュニケーションと自動テストが必要です。
Git Flow vs. Trunk-Based: 直接比較
Git FlowとTrunk-Based開発の主な違いを比較する
機能比較表
| アスペクト | Git Flow | Trunk-Based Development |
|---|---|---|
| Branch Complexity | 複数の長期間のブランチ | 短期間のブランチを持つ単一のメインブランチ |
| リリースのサイクル | 定期的なリリース | 継続的なデプロイ |
| チームのサイズ | 大規模なチームでは効果的 | 小規模なチームでは適している |
| Code レビュー プロセス | ブランチマージ時の正式なレビュー | 小さな頻度の変更の継続的なレビュー |
| テスト要件 | サイクル終了時のテストに焦点を当てる | 自動テストに大きく依存 |
| 学習曲線 | 複数のブランチにより複雑 | シンプルなワークフローが必要ですが、強力なテストが必要 |
| 展開リスク | ステージドリリースによりリスクが低減 | 頻繁な更新によりリスクが高まります |
| 復旧時間 | 遅いロールバックプロセス | 高速なリバース機能 |
各ワークフローの使用時期
Git Flow __CAPGO_KEEP_0__は、企業レベルのプロジェクトに適した構造化されたバージョン管理されたリリースが必要な場合に適しています。複数のサポートバージョンを管理するチームや、正式なQAまたはコンプライアンス要件があるプロジェクトに適しています。
Trunk-Based Development __CAPGO_KEEP_0__は、速度と柔軟性を優先するチームやプロジェクトに適しています。
- SaaSプラットフォームが迅速な更新が必要な場合
- 強力なCI/CDパイプラインを持つチーム
- 自動テストによって裏付けられたプロジェクト
- 継続的デプロイワークフローまたは頻繁なリリース
- モバイルアプリプロジェクトが定期的な更新が必要な場合
チームは、両方の方法を組み合わせて使用することもあります: Trunk-Based Developmentを使用してコアサービスと、正式なリリーストラックを持つプロジェクトでGit Flowを使用します。
次のステップ:どちらのアプローチでもCI/CD Pipelinesを設定する方法
CI/CD Pipelineの設定
Git Flow CI/CDの設定
- 開発ブランチPipeline:ユニットテスト、統合テスト、code品質チェック、ビルド検証、開発環境へのデプロイを実行します。
- リリースブランチPipeline:フルテストスイートの実行、セキュリティスキャン、リリース候補のビルド、ステージング環境へのデプロイ
- メインブランチPipeline:バリデーションテストの実行、バージョニングの処理、プロダクションビルドの作成、プロダクションへのデプロイ、リリースのタグ付け
Trunk-Based CI/CDの設定
- 機能ブランチPipeline: codeに焦点を当てた迅速なユニットテスト、codeスタイルのチェック、ビルドの検証、およびプレビュー環境へのデプロイ。
- メインブランチパイプライン:徹底した自動テスト、セキュリティスキャン、生産ビルドの作成、進歩的なデプロイ、および自動ロールバック機能をカバーします。
Capgo CI/CD統合
CI/CD設定のいずれかにライブオーバー・ザ・エアアップデートを追加するには、Capgoを簡単に統合できます。
Capgoは GitHubアクション, GitLab CI, Jenkins To enable live updates, staged rollouts, and instant rollbacks in both Git Flow and Trunk-Based pipelines. It meets Apple and Google requirements while offering support for both cloud and self-hosted deployments. [1].
概要と推奨事項
チームのサイズとCI/CDの成熟度に基づいて、以下の表に示すようにワークフローを選択してください。
| シナリオ | Git Flow | Trunk-Based |
|---|---|---|
| チームサイズ | 50名以上の開発者 | 50名未満の開発者 |
| リリースサイクル | 週1回または月1回 | 1日または複数回のリリース |
| [ | テストとQA | 伝統的なQAサイクル |
| 自動テストに焦点を当てる | デプロイメントモデル | 多バージョン、伝統的 |
| クラウドネイティブ、コンテナ化 | リスク耐性 | 保守的、規制されたセットアップ |
- 進歩的、迅速なフィードバック
- Maintain consistent code reviews and use feature toggles in both workflows. Align your pipeline configurations with the workflow you select.
一貫した__CAPGO_KEEP_0__レビューを維持し、両方のワークフローで機能フラグを使用する。選択したワークフローに基づいてパイプライン設定を整合する。
Git Flow とトランク ベースの CI/CD
あなたが CI/CD 自動化を計画するために使用している場合 Git Flow とトランク ベースの CI/CD CI/CD 自動化を計画するために使用している __CAPGO_KEEP_0__ CI/CD と接続する CI/CD 自動化の Capgo CI/CD の製品ワークフロー ネイティブ ビルドの Capgo Native Builds の製品ワークフロー 統合の Capgo Integrations の製品ワークフロー for the product workflow in Capgo Native Builds, Capgo Integrations for the product workflow in Capgo Integrations, CI/CD統合の実装詳細 CI/CD統合 GitHub アクション統合 GitHub アクション統合の実装詳細について
