プロジェクトバージョン管理のベストプラクティス: Yunxiao Feiliu Flow

1. 分岐規則

2. バージョン番号の指定

2.1 メジャーバージョン番号（最初のバージョン番号）

2.2 マイナーバージョン番号（反復番号）

2.3 マイナーバージョン番号

3. Flow のベストプラクティス (Alibaba Cloud Flow の使用)

3.1 全体フローチャート

3.2功行と阿弗の優れた実践

3.2.1 機能ブランチの作成

3.2.2 パイプラインの作成

3.2.3 毎日の環境リリース

3.2.4 プレリリース環境のリリース

3.2.5 危険なブランチがオフライン

3.2.6 本番環境リリース

3.2.7 本番環境リリース: ベースラインの作成

4. よくある質問

1. 分岐規則

2. バージョン番号の指定

ベストプラクティスでは、次のように構成される 3 桁のバージョン番号がよく使用されます。

VMajor バージョン番号.Minor バージョン番号.Minor バージョン番号

例: V1.0.0、V1.5.0、V1.13.1 など。

2.1 メジャーバージョン番号（最初のバージョン番号）

メジャーバージョン番号は、最初のバージョン番号またはトップバージョン番号とも呼ばれ、V の後の最初のバージョン番号です。メジャーバージョン番号は通常、プロジェクトのフェーズと製品の方向性を表します。プロジェクト契約の変更、大規模な API の非互換性、製品の方向性の変更、基盤となるアーキテクチャのアップグレードなどがない限り、簡単に更新しないでください。

なお、プロジェクトが正式にリリース、正式にインキュベート、正式にローンチされていない場合、最初のバージョン番号は 0 になります。第 1 フェーズでリリースされた場合は V1、第 2 フェーズでリリースされた場合は V2 になります。

2.2 マイナーバージョン番号（反復番号）

マイナーバージョン番号 (イテレーション番号とも呼ばれます) は、通常、イテレーションでリリースされる機能のセットを表します (イテレーションリリースには複数の機能更新が含まれます)。

たとえば、V1.1.0: 第 1 フェーズプロジェクトの最初の反復リリースバージョン、V1.2.0: 第 1 フェーズの 2 番目の反復リリースバージョン、第 1 フェーズの 18 番目の反復リリースバージョン: V1.18.0 など。

2.3 マイナーバージョン番号

マイナーバージョン番号は、いくつかの小さな機能やホットフィックスを一時的にリリースするための小さな反復です。通常、主要な機能アップデートは含まれず、特定の機能ポイントをアップグレードしたり、バグを修正したりするためにリリースされることが多いです。

3. Feiliu Flow のベストプラクティス (Alibaba Cloud の効果を活用)

Feiliu Flowをより有効活用するために、Alibaba Cloud Cloud Effectと組み合わせたFeiliu Flowのベストプラクティスについて説明します。

3.1 全体フローチャート

下の図は、最も楽観的な形のフローモデル図です。リリースブランチは複数の機能が統合されたバージョンであることがわかります。同時に、リリースはパイプラインを通じて整理され、さまざまなプロジェクト環境で構築できます。

3.2 公星と味のベストプラクティス

ここで、Gong Xing さんと Aji さんの 2 人の学生に次の講義をしてもらいたいと思っています。

3.2.1 機能ブランチの作成

プロジェクトチームはイテレーションV1.1.0を計画しており、イテレーションバックログには以下が含まれます。

バグを修正しました [Yuxing]

function1 機能開発 [Aji]

機能2 機能開発【Mr.ゴン・シン

イテレーションの開始時に、Gong Xing と Aji は、マスターに基づいて 3 つの機能ブランチを作成し、3 つのブランチの機能コードが相互に結合しないようにします。

ブランチ作成が完了すると、バージョンライブラリ内のブランチ状況は下図のようになります。開発を担当する学生は、お互いに影響を与えることなく、各ブランチで開発を行うことができます。

3.2.2 パイプラインの作成

Yunxiao では、パイプラインを [日常環境]、[プレプロダクション環境]、[プロダクション環境] の 3 つの環境に分けることができます。 Yunxiao のパイプラインは、さまざまな柔軟な構築手順、展開手順、手動チェックポイントテンプレートを提供します。さまざまなニーズに基づいてパイプラインプロセスを作成できます。

Gong Xing がプロジェクトパイプラインを作成した方法は次のとおりです (公式環境でのビルドの失敗は無視してください)。

日常環境とプレプロダクション環境は開発とテストに使用されることが多いため、手順は比較的簡単です。

つまり、[ブランチ統合] - [フロントエンドとバックエンドの構築] - [フロントエンドとバックエンドの製品] - [フロントエンドとバックエンドの展開]

注: [デプロイメントフェーズ] では、現在のパイプラインにデプロイされているマシンで、パイプラインとデプロイメント環境のバインドを完了できます。

プロジェクトのバージョン管理にはFlowを使用する必要があるため、最初のステップで[ソース]を選択するときに、選択したバージョンのライブラリでブランチモードを有効にする必要があります（同じパイプラインに複数のビルドソースがある場合（フロントエンドとバックエンドを同時にビルドする必要があるパイプラインなど）、ブランチモードの設定にサポートされるソースは1つだけです）

3.2.3 毎日の環境リリース

パイプラインの設定が完了したら、[実行] をクリックしてパイプラインをテストできます。実行時にはブランチモードがオンになっているため、[DEV デイリーパイプライン] に追加されたブランチをビルドリストに追加する必要があります。

実行後、ブランチマネージャーは 3 つのブランチ feature_bugfix、feature_function1、feature_function2 を統合し、新しい [origin/release] ブランチを生成します (以下を参照)。このリリースブランチは、日常の環境に特化したリリースブランチです。

この時点で、バージョンラインは次のようになります (赤い線は、Cloud Effect Branch Manager による自動統合を表します)。リリースブランチを直接変更してはいけないことに注意してください（競合を解決する場合を除く）

日々の開発が進むにつれて、ブランチの同僚がコードを送信してパイプラインの再実行をトリガーするたびに、ブランチマネージャーはブランチを統合して、最新のブランチコードを含むコミットを形成します。

3.2.4 プレリリース環境のリリース

毎日の努力の結果、Aji が担当する機能 1 と Gongxing が担当するバグ修正がセルフテストと毎日のスモークテストに合格し、検証のためにプレリリースに投入できるようになりました。

現時点では、これら 2 つのブランチを統合するには、プレリリースパイプラインに移動する必要があります。

統合する必要があるブランチを選択したら、[実行] をクリックして、これらの 2 つのブランチをプレリリース環境で公開します。

この時点でのバージョンラインは次のようになります (緑の線はプレリリースパイプラインブランチマネージャーによる統合を表します)。このようにして、ステージング環境では、バグ修正と function1 のみが含まれ、スモークテストに合格しなかった function2 は含まれない、最新のコードのクリーンなコミットが取得されます。

テスターと開発者は、プレリリース環境で機能のプレリリース検証を実行できます。

同様に、Gong Xing の機能 2 が開発およびテストされ、毎日のスモーク検証の後、彼のブランチがプレリリースパイプラインに追加されると、機能 2 の統合が完了します。この時点で、バージョンライン全体は次のようになります。

3.2.5 危険なブランチがオフライン

リリース前の検証とリリース前の環境でのテスト中に、テスターは、[Aji] が開発した機能 1 は完成しているものの、彼の変更が特定の機能の正常な動作に影響を与えること、そしてリリース日が迫っていることを発見しました。今から変更を加えるのは遅すぎるでしょう。この時点では、Aji の feature_function1 ブランチは危険なブランチであり、オンラインにすることはできませんでした。現時点では、プレリリースパイプラインで Aji のコードをオフラインにする必要があります。

オフラインになった後、多くの変更が伴うため、Yunxiao のブランチマネージャーは、コード競合解決の数を減らすために、feature_function2 ブランチと feature_bugfix ブランチをプレリリース環境用に作成された別のリリースブランチ [release_pre_2] に自動的に再統合します。

この時点で、バージョンラインは次の図のようになります (青い線は Cloud Effect Branch Manager の統合であり、元の origin/release_pre ブランチは廃止され、origin/release_pre2 に置き換えられています)。

3.2.6 本番環境リリース

テストしたブランチを本番パイプライン (ステップ 3.2.4 など) に追加し、ビルドして本番環境のリリースを完了します。本番環境で実行されているブランチもリリースブランチです。

実際には、本番環境のリリースプロセスに手動チェックポイント (承認) を追加することをお勧めします。つまり、パイプライン設定は次のようになります。

[ビルド] - [デプロイメント承認（手動チェックポイント）] - [グレーデプロイメント（バッチ）] - [本番デプロイメント（バッチ）] - [本番検証（手動チェックポイント）] - [ベースラインの書き込み]

3.2.7 本番環境リリース: ベースラインの作成

ベースラインを記述するということは、リリースブランチのコードを現在のマスターブランチにマージすることを意味します。これは通常、運用検証が完了した後に実行されます。

リリースが完了すると、全体的なバージョンラインのフローチャートは

4. よくある質問

Q1: Yunxiao Flow でコードレビューとプルリクエストを実行するにはどうすればよいですか?

A1: Yunxiao Flow をベースにチームで共同開発する場合、機能ブランチを中心にコードレビューやプルリクエストを行うことができます。つまり、リリースブランチの保護に加えて、機能ブランチも保護されます。機能ブランチへの直接送信は許可されておらず、プルリクエスト用に origin/feature_xxx_pr ブランチが別途作成されます。それだけでなく、本番環境への最終リリース前に手動でチェックポイントを設定してコードレビュー操作を実行することも可能ではありますが、コードレビューの粒度は異なります (前者は各コミットに基づき、後者はリリース全体の機能に基づきます)。チームのリリースリズムが緊急で人的リソースが不足している場合は、リリース前に手動チェックポイント + チームコードレビューという形式を採用できます。

Q2: Yunxiao Flow にはどのような開発シナリオや開発チームが適していますか?

A2: Yunxiao Flow は、1 回の反復で開発されるバックログにさまざまなビジネスドメインが含まれ、ブランチリリースや反復サイクルの重複 (1.2.1 と 1.3.0 を同時に開発およびテストするなど) のリスクがある、中規模のチーム規模のアジャイルチームに適しています。前述のベストプラクティスにあるように、[Aji]が開発した機能1はリリース直前に他の業務機能の開発に影響を与えることが判明したため、一時的に停止しリリースしない必要がありました。開発チームのメンバーが 2 人か 3 人だけであれば、すべてをシンプルに保つことができます。

Q3: Cloud Effect を使用せずに Flow を実装できますか?

A3: 現時点では、Cloud Effect を使用して Flow を実装するのが最も時間の節約になります。 Cloud Effect を使用しない場合は、リリースブランチ + Jenkins パイプラインのビルドを手動で管理する (またはスクリプトを使用してブランチを自動的にマージする) ことで、Flow を実装することもできます。

Q4: リモート機能ブランチは削除できないのでしょうか?

A4: リモート機能を削除する必要はありませんが、機能はリリース後にベースラインにマージされているため、リモートリポジトリに保持してもあまり意味がありません。

Q5: 複数のブランチを同時に開発しているときにコードの競合が発生した場合はどうすればよいですか?

A5: Yunxiao は完全な競合解決チュートリアルを提供しています。最も安全な方法は、統合ブランチをローカルでプルし、ローカルで競合を解決し、ビルドが成功した後にリモートリリースブランチに送信することです。

Q6: 次の反復のためにパイプラインを再作成する必要がありますか?

A6: いいえ、元のパイプラインに統合する必要があるブランチを削除し (リリース後に自動的に削除されます)、リリースする必要がある機能ブランチを再度追加するだけです。

Q7: プレリリースとデイリーリリースの両方に同じ機能が統合されています。再構築すると、新しい送信は両方の環境に影響しますか?

A7: プレリリースパイプラインとデイリーパイプラインが同じ機能ブランチに統合されると、開発者のコード送信によって再デプロイメントがトリガーされ、プレリリース環境とデイリー環境の両方で最新機能が提供されます。

Q8: 複数のリリースブランチ (デイリーリリースとプレリリースなど) が相互にマージされますか?

A8: いいえ、リリースブランチは互いに独立しており、互いに何の関係もありません。共通しているのは名前だけです。

Q9: gitflow と比較すると、AoneFlow はより柔軟で自由度が高く、リスク管理もより信頼できます。では、AoneFlow は最適なバージョン管理モデルなのでしょうか?

A9: 最適なバージョン管理モデルはありません。最適なのは、特定の生産状況に適したものです。