この記事では、ベータスタンドを作成して通常のgitflowに埋め込む方法について説明します。 読者とともに、これに関連する問題からgitを操作するための新しいスキームに進みます。
gitflow
当社では、よく知られているgitflowを使用しました。 それが何であるかを知っている人は、次のセクションに直接進むことができます。 知らない人のために、私はあなたに話します。
主な作業は開発ブランチで実行されます。 新しい機能ごとに個別の機能ブランチが作成されます。 開発中に機能ブランチをマージすると、アプリケーションが組み立てられ、テストスタンドに配置されます。テストスタンドでは、QAエキスパートがその動作を検証します。
開発で見つかったバグごとに、修正された修正プログラムブランチが作成されます。 次に、修正プログラムのブランチが開発にマージされ、テストベンチが更新され、QAが再度チェックされます。
開発ブランチがデバッグされ、リリースのために十分な機能がそこに蓄積されると、リリースブランチが作成されます。 これには常にマスター内でいつでも見つけることができるコードが含まれており、それによって生産スタンドを更新します。
ベータスタンドを作成するための前提条件
説明した回路にループが存在するため、テストベンチでロールアウトし、チェックし、修正し、再びロールアウトすると、膨大な数のエラーが消えます。 しかし、悲しいかな、すべてではありません。
もちろん、QAはうまく機能します。マスターに近づくにつれてバグの数は減りますが、次の理由で解消できません。
実際のユーザーの動作は、はるかに複雑で予測不可能な合成テストケースです。
実際のユーザーの機能（デバイス、OS、ブラウザー、個人設定など）は考慮されません。
- テストは、テストデータベースを備えたテストベンチで実行され、実際のデータベースとは異なります（アーティファクトがあります）。
ベータスタンドの目標と目的
ベータスタンドを使用したテストでこれらの問題を修正することにしました。 システムの内部ユーザー、顧客、信頼できる顧客、その他の人に早期アクセスを提供します。
現在、QAスペシャリストによるチェックが行われるスタンドの開発後、新機能がベータスタンドに到達し、そこで実際のユーザーが作業を行います。 ベータスタンドの更新後、すぐにベータテストの開始が通知されます。 アプリケーションのベータ版のエラーは、ロギングシステムに表示されます。 定期的に修正され、ベータスタンドが更新されます。 エラーが発生しなくなると、リリースが作成されます。 したがって、幅広いユーザーがアプリケーションの安定したバージョンを受け取ります。
ベータテストの段階では、ユーザーからフィードバックを得て、導入された機能が幅広いユーザーにとって便利であるかどうか、および何を変更する必要があるかを知ることができます。 ベータ版は、アプリケーションの一種のパイロット版です。
このスキームは、開発の主要な段階であるアルファ、ベータ、リリースに対応しています。
継続的デリバリーの側面、つまり どの時点でプレリリースとリリースを作成するか。 継続的インテグレーション、つまり ベータを考慮してgitで作業するまさにそのスキームを開発します。
gitflowでベータ版を実装しようとしています
最初に思い浮かぶのは、リリースブランチを使用してベータ版に展開することです。 この場合、リリースブランチはリリースの意図と見なされます。 つまり、プレリリース版（ほぼベータ版）です。 そして、それは調和して判明し、gitflowで何も変更する必要はありません。 CDに新しいルールを作成して、ビルドを作成/変更リリースブランチに配置するだけです。
このようなスキームは次のようになります。
注：グラフ上の点線は、BASEコミットを示しています。
グラフはどうなりますか？
- 開発用の機能ブランチがタスク用に作成されます。
- 機能ブランチは、開発ブランチにマージされます。 開発ブランチを変更する場合、開発スタンドで計算が行われます。 QAスペシャリストがテストを開始します。
- 開発で見つかったエラーの下に、エラーが修正され遅延される修正プログラムブランチが作成されます。 エラーが検出されない場合、開発ブランチのリリースブランチが作成され、開発ブランチの安定状態が修正されます。
- リリースブランチを作成すると、アプリケーションアセンブリ（リリース候補）が作成され、ベータスタンドに展開されます。 ユーザーに通知が送信されます（たとえば、対応するタスクのタスクマネージャーでコメントが作成されたり、メッセンジャーでメッセージが作成されたりします）。
- リリースブランチがデバッグされると、マスターブランチにマージされ、プロダクションはアプリケーションをビルドし、プロダクションにロールアウトします。
- 戦闘にバグがある場合、修正されたマスターから修正プログラムのブランチが作成されます。 次に、連続したマージによってすべてのブランチに沿って伸びます。
一見、作業スキーム。 次に、その長所と短所を見てみましょう。
長所：
最新に保つ必要がある少数の主要なブランチ。 ほとんどの場合、開発者とマスターの2つだけです。
- PRを作成することで、GitHubからメインブランチを直接更新することができます。リベースするためにブランチを自分でプルする必要はありません。 それでも、競合が発生した場合と同様に、新しいバージョンを置くためにブランチを自分でプルする必要があります。
短所：
最初の問題は、新しいリリースアプローチを待たずに、修正プログラムをマスターに追加するときに発生します。 さて、修正プログラムをマスターに、次にリリースと開発にマージできます。これは問題ではありません（マージと混同しない限り）。 この問題は、リリースブランチがない場合に発生します。 しかし、手動での場合を除き、リリースブランチなしでベータ環境を更新する方法。 どういうわけか正しくありません。CDスキームが設定されています、とあなたは言います、私は同意します。
メインブランチでホットフィックスを作成する際にタイムラグがあります。 提示されたフロー図では、マスターへのホットフィックスの追加は次のようになります：ホットフィックス→マスター→開発→リリース。 リリースはdevよりも重要であり、変更はその前に現れるはずなので、修正プログラム→マスター→リリース→devのようになります。 devを維持するために、修正プログラムを追加しても、リリースブランチですぐに動作しない場合があります。devには、現在の（開いている）リリースブランチに該当しない変更が含まれている場合があります したがって、ベータ版スタンドにホットフィックスが表示される前に、次のリリースを待つ必要があります。 または、たとえば、ベータ版に修正プログラムを追加する必要がある場合、修正プログラム→ベータ→マスター→devのようなフローがありますが、修正プログラム→ベータ→dev→マスターのようになります。 このスキームでは、因果関係の原則に違反しています。
メインブランチ（リリースおよびdev）の回帰更新はマージコミットを介して行われ、CIでのCDスキームの賦課を複雑にします。 また、このスキームでは、混乱するのは簡単です-多数の自由度。 たとえば、修正プログラムをマスターにマージしてから、リリースブランチをリリースにマージできますが、devは忘れてください。
「左」マージコミットのブランチを更新するため、自動バージョン割り当てはできません。 混乱する可能性のあるバージョン番号を手動で書き留める必要があります。 目的のブランチで、手動でバージョンコミットを行う必要があります。 また、メンテナーがタグのインストールを忘れて、アプリケーションが古いバージョンでダウンロードされる可能性があります。これにより、誤ったエラーログが記録されます。
- ベータシーンを更新する明白な方法。 リリースブランチはマージ後に削除されます-これはスキームの特性です。
ベータ版の新しいCIスキーム
これらの問題を取り除きましょう。
ベータスタンドは常に存在するため、リリースブランチを常に存在させる必要があります。 ベータ版と呼びましょう。 その後、リリースブランチがなくても、ベータスタンドに修正プログラムを追加できます。 ただし、この場合、ブランチの数が増えると、マージコミットが過剰になる問題が大きくなります。 この問題を解決するには、マージ戦略でメインブランチを更新することを拒否するだけで十分です。
結果のフローを次のようにグラフィカルに表示できます。
注：グラフ上の点線は、BASEコミットを示しています。
グラフはどうなりますか？
- gitlowの場合と同様に、タスクの機能ブランチが作成されます。
- 機能ブランチは、開発ブランチにマージされます。
- 開発ブランチからプレリリースブランチが作成され、開発ブランチの安定状態が修正されます。 開発スタンドでの組み立てとレイアウトが実行されます。 QAスペシャリストがテストを開始します。
- バグが見つかった場合、プレリリースブランチからホットフィックスブランチが作成され、バグは除去され、ブランチがマージされます。 その後、プレリリースの左側にあるすべてのブランチは、プレリリースから避難します。 機能がQAテストに合格し、公開テストの準備ができている場合、プレリリースブランチをベータブランチにマージします
- ベータブランチが変更されると、アプリケーションのベータアセンブリが作成され、ベータスタンドに展開されます。 ユーザーは機能に早期にアクセスできます。 ロギングシステムでベータ版を使用するプロセスでは、発生したエラーが蓄積されます。 ホットフィックスブランチを使用して定期的に修正されます。 次に、ホットフィックスブランチがベータブランチにマージされ、スタンドが更新されます。 ベータブランチの変更ごとに、左側のメインブランチをリベースする必要があります。 プレリリースブランチが既に存在する場合は、それらをdevから切り離す必要があります。
- アプリケーションのベータ版ですべてのエラーが解消されると、リリースブランチが作成されます。
- リリースブランチがマスターに残っています。
- 本番環境にバグがある場合、修正プログラムがマスターから作成され、修正されます。 次に、ホットフィックスは、メインブランチのBASEを作成元のHEADブランチに転送することにより、すべてのブランチに沿って拡張されます。
注：すべての段階（プレアルファ、アルファ、ベータ...）でメインブランチを更新することは、リリースの責任です（プロジェクトメンテナー）。 チームメンバーはdevブランチでのみ作業します。
回路はかなりクールに見えますよね？ その長所と短所を見て、前のものと比較してみましょう。
長所：
CI / CDのベータ版の役割が改善されました。 修正プログラムおよびそれを介した変更の取得に問題はありません。 つまり 因果関係の原則に違反しない場合、フローは次のようになります：修正プログラム→マスター→ベータ→dev。
自動バージョン管理と変更ログの収集が可能です。これはライブラリにとって特に重要です。 間違いの可能性はありません。
テストは再度実行されないため、変更の受け入れプロセスが高速化されます。
追加のマージコミットはありません。
- CI / CDは、開発段階（ wikipedia ）（プレアルファ、アルファ、ベータ、リリース候補、リリース、ポストリリース）に完全に対応しています。
短所：
多数のブランチ。 しかし、リリースの責任者がそれらを扱うので、これは怖くないです。 各ブランチには、自動テストにおける独自の役割もあります。これについては、以下でいくつか説明します。
- githubを介してブランチの関連性を管理する方法はありません。 それでも、マージ戦略（前のスキームで使用されている）の場合、競合が発生する可能性があります。そのため、ブランチをローカルマシンにプルする必要があります。
開発段階との関係
提案されたスキームは、ソフトウェア開発のすべての段階を完全に満たしています。
pre-alpha-機能は作成されていますが、QAスペシャリストによってまだテストされていません。 多数のバグが含まれている場合があります。
alpha-この段階で、アプリケーションは組み立てられ、開発ブースに展開されます。そこで、QAマニュアルが動作をチェックします。
beta -QAスペシャリストによってテストされたアプリケーションの条件付き安定ビルド。 この段階でのアセンブリは、実際のユーザーがテストするためのベータスタンドに配置されます。
候補リリース -テストのすべての段階に合格し、現在リリースを待っているアセンブリ。
- リリースは、アプリケーションの安定バージョンです。
私たちのプロジェクトには多数の自動テストがあります。 すべてのテストには約1時間かかります。 機能実装の各段階のブランチでのPRの採用をスピードアップするために、この段階で重要なテストのみを実行します。 たとえば、pre-alphaのコードを受け入れるために、最も単純なテストであるlintとunitを実行します。 ベータ版の導入段階では、統合テストも実行されます。 リリース候補の段階では、有声テストに加えて、受け入れテストも開始されます。 さらに、この段階では、異なるオペレーティングシステムを使用し、異なるブラウザで実行しているランナーでテストが実行されます。 リリースを作成した後（リリース後のフェーズは図に示されていません）、煙テストが実行されます。
興味深いものが舞台裏に残っている場合は、コメント欄で質問してください。
参照：