継続的インテグレーションと既存のUI自動化テストの変更
私たちのチームは現在、製品に含まれている機能を変更するという状況に直面しています。この機能には、Selenium自動化テストが関連付けられています。
UIを含め、システムのかなり大規模なオーバーホールを行っています。この作業にはかなりのスプリントが必要です。この間、他のチームが、現在存在する機能に影響を与える作業を行う可能性があります。このため、問題を検出できるように、機能の既存の自動化テストをそのままにしておく必要があります。
もちろん、変更が行われた後のように、機能の自動化を作成する必要があります。 Dev/QAの観点からこれを行う最も効率的な方法は、別のブランチで既存のテストケースを変更し（ローカルでテスト）、機能の準備ができたらそれらの変更をマージすることです。そうすれば、既存の自動化は引き続き機能し、各テストを複製するために余分な作業を行う必要はありません。
ただし、この個別のブランチは、継続的インテグレーションの原則（私たちの組織が順守することを好む）にうまく適合しません。変更のためにテストを複製するという余分なオーバーヘッドを実行する唯一のCI準拠のオプションですか？
私はこの観点からそれを見ようとします：
定義された時間間隔で並列ブランチを開発します（もちろん、これは「標準」CIモデルとは異なります）。
これにより、テストも並行して開発されます。それに応じてテストを分岐します（メインのソースコードをマージするときに、テストをトランクにマージし直します）。
そのブランチをCI環境にも適用します。たとえば、サーバーで自動ビルドとテストを行う場合は、サーバーに両方、トランク、およびブランチが存在する限り、ブランチ
継続的インテグレーション手法をトランクとブランチに別々に適用することはできます
後でマージする労力を最小限に抑えるために、トランク内の変更をできるだけ頻繁に開発ブランチにマージして戻すようにしてください。1日1回が最適です。これは、devブランチのUIがトランクと異なる領域では単純ではない可能性があるため、その間、その領域でのトランクUIへの変更を最小限に制限するようにしてください。
ご覧のとおり、「CI」パスを離れて長期分岐を作成してマージする場合、テストとCIを含むソースコード全体に対して、完全に実行する必要がある場合があります。環境、追加の管理作業が発生します。ただし、純粋なCIが必要な開発モデルではない場合があり、それだけの価値がある場合があります。
編集：別の方法として、VCS内での分岐を回避し、 フィーチャートグル で問題を解決することもできます。実行時に古いUIと新しいUIを切り替えることができるように、その切り替えを設計できます。これは、Seleniumテスト内で使用できます。古いテストが古いUI（機能が無効）に対してのみ実行され、テストが新しいUI（機能が有効）に対してのみ実行されるようにテストを変更します。