AoneFlowはTrunkBasedとGitFlowの両方の長所を取り入れながら、高品質なソフトウェア製品をタイムリーにリリースするための新しい自動化ツールとブランチ管理ツールを導入しています。

本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。

自動化と新しいブランチ管理プロセスは、ソフトウェア開発に革命をもたらしています。

TrunkBasedとGitFlowは、簡単な統合と管理可能な要件機能という点で、ほとんどの開発者のブランチ管理ニーズを満たすことができますが、アリババは、面倒な手動操作をせずに、より効率的なシステムと、改善されたブランチ管理ツールを必要としていました。これを受けて、アリババの技術チームは新しいブランチ管理モードAoneFlowを開発しました。AoneFlowはTrunkBasedとGitFlowの両方の長所を取り入れながら、新しい自動化とブランチ管理ツールを導入し、高品質のソフトウェア製品をタイムリーにリリースすることを保証しています。

ブランチ管理の基盤：TrunkBasedとGitFlow

AoneFlowは、ソフトウェア開発者が最もよく使うブランチ管理手法であるTrunkBasedとGitFlowの構造と機能を部分的にベースにしています。どちらのシステムも便利な機能を提供しており、既存のシステムをベースにしたAoneFlowは、ソフトウェア開発者にとって親しみやすいという利点があります。

TrunkBased

TrunkBasedの利点は継続的なインテグレーションです。その構造は、単一のトランクブランチと多数のリリースブランチで構成されています。各リリースブランチは、オンラインデプロイやHotfixのために、特定のバージョンのコミットポイントでトランクから作成されます。明示的な機能ブランチはありません。GitFlowでは各開発者がローカルブランチを持つことができるのに対し、TrunkBasedは、存続期間の短い機能ブランチを除外しません。しかし、この機能はTrunkBasedの開発者には広く使われていません。

TrunkBasedは、いくつかの欠点があるため、近年GitFlowに人気を落としています。まず、同じトランクでコーディングしているチームの数が多すぎると、リリース時にエラーが発生する可能性があります。FeatureToggleはその解決策として実装されましたが、頻繁な統合と適切なテストカバレッジが要求されるため、開発チームの能力に過度の負担がかかります。その結果、TrunkBased は、複数の過去のバージョンを同時に管理する必要がない SaaS プロジェクトで使用されることがほとんどです。これらのプロジェクトは、主にマイクロサービスの変革を経た小規模なサービスです。

TrunkBasedモードには2つの進化があります。OneFlowとMulti-Trunkです。OneFlow は TrunkBased と同じ機能を多く使用しますが、動作フローの定義がより厳密になり、Hotfix ブランチのような機能が追加されています。Multi-Trunk は、デュアルトランクと固定開発ブランチに加えて、固定リリースブランチを使用します。

GitFlow

GitFlow は TrunkBased とは構造が異なります。トランクブランチと多数の機能ブランチ、リリースブランチ、Hotfixブランチで構成されています。GitFlowは、各段階の操作定義が明確であることから、以前はプロセス指向の企業では最も利用されていました。しかし、GitFlowはユーザーフレンドリーではなく、面倒なマージルールが多数含まれています。マージの競合や統合テストの問題は、しばしば批判の的となっています。

あまり知られていないブランチ管理方法にGithubFlowがありますが、これは基本的にTrunkBasedに個人のウェアハウスとPull Requestコードのマージ操作を追加したものです。このプロセスは、同じ倉庫に個々のブランチを追加するのと似ているため、分散したチームに最適です。GithubFlowにも独自の進化があり、GitlabFlowは複数の環境でのデプロイを利用し、その環境内で倉庫とブランチを関連付けています。

新たな進化：AoneFlow

AoneFlowの構造、機能、プロセスは、いくつかの重要な分野でTrunkBasedやGitHubとは異なります。

前身と同様に、AoneFlowはシンプルな継続的インテグレーション（TrunkBased）と管理可能な要件機能（GitFlow）の実現を目指しています。また、トランクブランチ、機能ブランチ、リリースブランチという3つのブランチタイプの基本的な構造も同様に維持しています。

しかし、AoneFlowは、ブランチ管理のワークフローのための3つのコアルールを確立することで、前任者から出発します。

1、作業を始める前に、トランクから機能ブランチを作成します。
2、フィーチャーブランチを組み合わせてリリースブランチを形成します。
3、オンラインフォーマル環境にリリースした後、対応するリリースブランチをトランクにマージし、トランクにタグを追加し、リリースブランチに関連付けられた機能ブランチを削除します。

ルール1. フィーチャーブランチの作成

AoneFlowのfeatureブランチはGitFlowから採用されました。新しいジョブが開始されると（新しい関数を作成したり、エラーを解決したりなど）、最新のリリースバージョンを表すトランクから「feature/」という接頭辞を持つfeatureブランチが作成されます。コードの変更はこのブランチでコミットされます。各ジョブは1つのfeatureブランチに対応しており、以下の図のように、変更を直接トランクにコミットすることはできません。

機能ブランチの作成

ルール2. ブランチの形成を解除する

このルールはAoneFlowの最も革新的な成果です。

既存のブランチ管理方法では、GitFlowは完成した機能ブランチを共通のメインライン（開発ブランチ）に戻してマージし、共通のメインラインからリリースブランチを引っ張ってきます。TrunkBasedも同様に、必要な機能がトランクブランチ上で開発されるのを待ち、トランクブランチ上の特定の場所からリリースブランチを引っ張ってきます。

対照的に、AoneFlow はトランクから新しいブランチを引っ張ってきて、リリースや統合を待っているすべての機能ブランチをマージしてリリースブランチを作成します（通常は "release/"という接頭辞で示されます）。

これはシンプルでありながら、その用途は多岐にわたります。リリースブランチは柔軟に使用でき、アセンブリラインツールを使用して特定の環境に関連付けられます(例えば、リリース/テストブランチはデプロイメントテスト環境とペアになっています)。このツールは、コード品質スキャンと自動テストレベルを一連の多様な環境に接続します。最後に、出力されたデプロイメントパッケージは、適切な環境に直接リリースされます。

リリースブランチの形成

より高度なレベルでは、リリースブランチは、段階的リリースと正式リリースを連鎖させるようなタスクのために、複数の環境に関連付けることができます。これにより、信頼性を確保するための人間による検査ステップが追加されます。また、反復計画に従って機能ブランチを関連付け、反復進化によって固定リリースブランチを作成し、一連の環境をリリースブランチのアセンブリラインに紐付けることで、継続的な統合アセンブリラインを作成することもできます。また、すべての機能ブランチを関連付けて、すべてのコミットで統合テストに専念させることで、TrunkBasedの効果を実装することもできます。

さらに、リリースブランチの機能の構成は動的で、簡単に調整できます。

例えば、「アジャイルオペレーション」を採用している小規模な企業では、市場戦略の変更により機能のリリースを断念したり、エラーのために土壇場で機能を削除しなければならないことがあります。通常、これには手動で「コードをチェックする」か、開発ブランチまたはトランクブランチに1つずつマージされた関連するコミットメントを削除する必要があります。

対照的に、AoneFlow では、リリースブランチを 1 分以内に構築することができます。これは、元のリリースブランチを削除し、トランクブランチから同じ名前の新しいリリースブランチを引っ張ってきて、保持する必要のある機能ブランチをマージすることで行われます。この一連の動作は自動化することができ、クリーンで汚染の心配がありません。

最後に、リリースブランチは疎結合されているため、異なる機能の組み合わせに基づいて複数の統合環境を統合してテストすることができます。また、異なる環境での機能のデプロイタイミングを管理するのにも便利です。疎結合であるにもかかわらず、リリースブランチ間には相関関係があります。テスト環境、統合環境、プレリリース環境、段階的環境、オンラインフォーマル環境のリリースステップは、通常、順次実行されます。これは、ユーザーが要件を設定できることを意味し、前の環境で検証をパスした特性だけを次の環境に転送してデプロイすることができることを意味します。その結果、漏斗状の機能リリースストリームが作成される。

さらに、アリババは、次項で説明するリリースブランチ間の機能の組み合わせを自動化して移行するための統一プラットフォームを作成しました。

ルール3. ブランチのオンライン展開をリリースする

リリースブランチのアセンブリラインがオンラインフォーマル環境のデプロイを完了すると、対応する機能がリリースされたことを意味します。この場合、リリースブランチはトランクにマージされなければなりません。コードウェアハウスに過去の機能ブランチが大量に蓄積されるのを避けるために、すでにオンラインになっている機能ブランチもクリーンアップする必要があります。

AoneFlow では、トランクブランチの最新バージョンは常にオンラインバージョンと同じです (GitFlow と似ています)。ユーザーが過去のバージョンをトレースバックしたい場合は、トランクブランチ上で対応するバージョンラベルを見つけるだけで済みます。

構造：ルール3

追加ルール

AoneFlowでは、ルール1-3と並んで、いくつかの実用的な操作が追加されています。例えば、Hotfix がオンラインになった場合、通常の処理方法ではオンライン環境に対応したリリースブランチ（Hotfix ブランチに相当）を新たに作成します。そして、リリースブランチ用の一時的な組立ラインを作成し、リリース前の検査やスモークテストを自動的に実行できるようにします。

AoneFlowでは、トランクブランチ上のバージョンラベルの場所を見つけ、その場所に直接Hotfixブランチを作成することができます。これにより、ユーザーはいくつかの重要な操作を効果的に行うことができます。

対応するオンラインフォーマル環境に基づいて、リリースブランチの機能ブランチをクリアします。
リリースブランチを直接修正します。
既存のアセンブリラインを使用した自動リリース

ユーザーエクスペリエンスの最適化

アリババは、ブランチ管理プロセスの最適化を一貫して模索しています。最近では、Java開発のベストプラクティスを記録し、Alibaba Java開発マニュアルにまとめました。これにより、チーム全体でJava開発を標準化し、作業の品質と効率を向上させることができました。

また、標準化によって、リリースブランチの再構築などのタスクベースの問題を解決することができました。リリースブランチの再構築には合併が必要で、その後、コードをコンパイルして新しいデプロイメントパッケージを生成する必要があります。しかし、ソフトウェアの機能がサードパーティ製のソフトウェアパッケージに依存している場合、ソフトウェアの動作に矛盾が生じる可能性があります。

解決策として、オンラインリリースのコードには、「SNAPSHOT バージョン」や非公式リリースを含む依存パッケージを使用してはならないというルールをコーディングガイドラインに追加しました。このガイドラインにより、私たちのチームは、制作する製品の品質をよりコントロールできるようになりました。

また、開発者の作業を容易にするためのツールを多数追加しました。例えば、AoneFlowプラットフォームでは、開発者が手動でGitコマンドを使ってブランチを作成したり、マージしたり、変更したりする必要がなくなりました。手動での作業はエラーが発生しやすく、時間がかかります。AoneFlowプラットフォームは、研究開発プロセス全体を制御し、研究開発の効率を高めるために多数のビルトインサービスコンポーネントを追加することで、これらの問題を否定します。このプラットフォームは、いくつかの重要な利点を提供します。

完全なプロセス自動化
リリースブランチの改善
ブランチ関連管理の充実

フルプロセス自動化

AoneFlowプラットフォームは、要件の提案、要件のタスクへの分割、機能ブランチのオンライン作成、機能ブランチの集約によるリリースブランチの生成、テンプレートに基づいたテスト環境の自動作成、後期の運用・保守（O&M）などの機能のためのブランチ管理プロセスの自動化を導入しています。

フロントエンドでは、AoneFlow は機能ブランチの関連付けと監視要件を制御することで、機能ブランチの名前の正規化を保証します。バックエンドでは、リリースブランチの関連付けとデプロイメントを処理し、ソースバージョンの信頼性を確保します。全体的に、AoneFlow は Alibaba グループのオンラインデプロイメントの約 80% を処理しています。

改良されたリリースブランチの組み立てライン

AoneFlow のライフサイクルには多数のコードの分岐があります。これらのブランチの作成と更新には複雑なアクションが含まれています。このプロセスを自動化することで、品質と効率がヒューマンエラーによって失われることがないようにします。

AoneFlowは自動化されたCI/CDアセンブリーラインを使用して、コードのブランチを作成し、更新します。このアセンブリラインは、ライフサイクルの中でコードのすべての独立したブランチをリンクし、それらをより効率的に意図された機能（例えば、統合テストのためのコミットコード）に向けて方向付けるようにします。これは特にリリースブランチに当てはまり、特定のデプロイメント環境に関連付けることができます。ブランチにマージされた新しいコードをチェックし、より効率的にデプロイすることができます。

理想的なブランチ管理のシナリオでは、各ブランチはその役割にマッチしたアセンブリラインとペアになるべきです。AoneFlowのリリースブランチはGitFlowよりも比較的固定されており、統合が容易なため、利用可能なほとんどすべてのアセンブリラインツールがAoneFlowと互換性があります。

また、AoneFlowにはコードレビュー、セキュリティチェック、オンラインアセンブリラインのデプロイメントなどの追加機能も含まれており、開発チームのユーザーエクスペリエンスを向上させ、最適化を実現しています。

改良されたブランチアソシエーションのメンテナンス

フィーチャーブランチとリサーチブランチの関連付けのメンテナンスは、AoneFlow が対処する独自の問題です。

既存の機能の組み合わせに変更を加える際には、リリースブランチがどの機能ブランチから来たのかを記憶しておくことが重要です。例えば、ある機能が特定のリリースブランチから削除された場合、その機能が含まれていないブランチも含めて複数の機能ブランチがマージされ、元のリリースブランチに置き換わります。どのブランチがマージされたかを手動で記録するのは難しく、時間がかかります。

AoneFlowには、このプロセスを改善するいくつかの自動化機能が含まれています。特定の機能の組み合わせが低レベルのリリース環境（統合テストなど）で検証された場合、そのコンテンツを高レベル環境（プレリリースなど）の対応するリリースブランチに直接移行します。これにより、オンライン版がリリース前の検証に合格していること、プレリリース版が統合検証に合格していること、その他の重要なプロセスを確実に実行します。これにより、すべてのリリースブランチが一連の流れで結ばれます。この処理は通常のGitコマンドでも完了しますが、AoneFlowのビジュアルツールを使うとより直感的に処理を行うことができます。

また、AoneFlowでは、対応するブランチのデプロイ環境のマシン情報や運用記録など、コードウェアハウス内のブランチの状態を統一的に表示することができます。

概要

アリババのAoneFlowは、TrunkBasedとGitFlowの強みを活かしたブランチ管理の進化形です。

この新しいブランチ管理方法のメリットは以下の通りです。

TrunkBasedをモデルにした簡単な統合
GitFlowをモデルにした、管理しやすい要件機能
効率と品質を確保するためのルールとプロセスを定義
自動化された機能
リリースブランチ管理の改善
改良されたブランチアソシエーションのメンテナンス

AoneFlowは、ソフトウェア開発者がダイナミックなブランチ管理のライフサイクルに適応し、効率的に作業を行い、高品質なソフトウェア製品をリリースできるようにする柔軟なプラットフォームを提供することで、ソフトウェア開発者が製品をよりコントロールできるようにします。

Alibaba Tech

アリババの最新技術のファーストハンド、詳細、詳細情報 → Facebookで「Alibaba Tech」を検索

アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ