並行機能開発におけるバージョン管理
アプリケーションコードで使用されるライブラリ（npmパッケージ、[〜＃〜] lib [〜＃〜]））があります（[〜＃〜]アプリ[〜＃〜]）。 APPのリリースでは、複数の機能が並行して動作します。これらの機能はLIBからのサポートを必要とする場合があるため、そこでも変更を行う必要があり、LIBはsemvarを使用しました。
F1やF2などの複数の機能がAPPで処理されている場合、LIBがリリースされ、F1の場合はx.y.1、F2の場合はx.y.2と表示されます。問題は、機能が並行して開発およびテストされており、F2が上陸したがF1が上陸しない可能性があることです。その場合、LIBのリリースx.y.2には、x.y.1の望ましくないコードが含まれています。
今私は2つの方法を使用してこれを解決します：
最適にLIBを解放し、望ましくないコードを元に戻し、
x.y.3を解放します。これは、基本的にx.y.2なしでx.y.1を解放します。このアプローチの問題は次のとおりです。x.y.3は新しいリリースであり、おそらく再度テストする必要があります。- バージョンを元に戻すオーバーヘッド。
リリース前にLIBのF1およびF2ブランチのダーティコードを使用して、APPをテストします。機能の1つが上陸する準備ができると、バージョンがリリースされます。 F2が着陸する準備ができているとしましょう。それから、LIBの
x.y.1がリリースされ、F2がサポートされます。このアプローチの問題は次のとおりです。- APPのリリース直前の依存関係（LIB）バージョンのリリースのオーバーヘッド。
- Gitブランチを使用したバージョン管理されていないコードは管理が難しく、バグが発生しやすくなります。
git flowに似たものを使用し、LIBのリリースブランチから機能を元に戻すと、F2を実行する必要があるため、元に戻すとエラーが発生する可能性があるため、さらに多くのエラーが発生します。また、テストが（F1 + F2）で実行されている間、新しいリリースブランチは（F1 + F2-F1）になるため、テストは無効になります。
これらのソリューションには両方とも問題があります。並行開発が順次semvarに出会うこのシナリオを解決する方法を知りたいのですが、リリースの直前に機能を元に戻すことは問題であり、異常な習慣であることに気づきました。
前もって感謝します。
バージョン管理を分離し、リリースの機能にします。これは、LIBからのAPPのバージョン管理と機能性を意味します。
APPとLIBの両方について、一連のまとまりのある変更をバージョン管理します。たとえば、F1とF2が関連性の高い変更の2つのセットである場合、1つが終了したらすぐに、それらをLIBに組み込み、テスト済みのLIBを用意します。先に進んでLIBをリリースする場合は、バージョンを適切に増分できます。もう一方が完了するのを待って、一連の変更に基づいてバージョンLIBを待つこともできます。セマンティックバージョニングを使用しているため、バージョン識別子の各部分をいつどのように更新するかについてのルールがあります。
機能開発環境をアップストリームブランチと同期させておく必要があります。修正リリースを使用しているため、安定したmasterブランチ、「バージョンが次のバージョン」であるdevelopブランチ、およびdevelopにマージされるさまざまな機能ブランチを用意することをお勧めします機能が完成してテストされたとき。 developに新しい変更がある場合、それらはまだ開発中のすべての機能ブランチに組み込む必要があります。 git flow のようなアプローチをリリースブランチで使用することも、masterをリリースブランチとして他のアプローチを使用することもできます。
「gitブランチを使用したバージョン管理されていないコードは管理が難しく、バグが発生しやすい」とわかった場合は、他にも問題があり、それらを解決する必要があり、バージョン管理と削除の複雑なシステムを開発しようとしないことをお勧めします変更。
私は書きました gitフロー分岐モデルでQAテストをどこで行うべきかについてのより広範な回答 。時間とリソースに制限がない場合の答えは、QAは複数のブランチで機能する必要があるということです。他の既知の優れたソフトウェアで機能を分離してテストするには、機能ブランチが最適な場所です。ただし実際には、ほとんどのテストはdevelopブランチとリリースブランチ（使用している場合）で行われる可能性があります。品質を確保するのはチーム全体の責任です。
テストを自動化することは、特に回帰テストに関しては、長い道のりになります。テストに合格した安定したdevelopブランチがあり（それらのテストはまともな品質である）、機能ブランチでテストが失敗する場合、古くなったテストがあるか、回帰が発生していることがわかります。探索的テストと自動化のための新しく興味深いテストケースの特定に人々の努力を集中させることは、長い道のりです。手動テストは拡張できないことがわかります。 N個の機能/機能に対して回帰テストを実行するのに2〜3日かかる場合、2N個の機能/機能を実装するとどうなりますか？手動テストを完全に置き換える必要はありませんが、それに依存すべきではありません。
また、x.y.2から機能を削除したx.y.3バージョンを持つことは珍しいことも追加します。
ビルドプロセスをよりスマートにします。
ストリーム/機能ビルドで、同じストリーム/機能のライブラリをチェックアウトしてビルドし、ローカルでリンクしてから、メインプロジェクトをビルドします。ライブラリに補足的なストリーム/機能ブランチがない場合は、ライブラリのリリースバージョンを使用します。
実際、これはビルドスクリプトの一部でなければなりません。ローカルでビルドする場合、開発者はこれを無料で入手できます。
ストリームをリリースする準備ができたら、コードをメインラインにマージします。メインラインからのビルドは、リリースされたバージョンのライブラリを使用します。