プルリクエストを使用したGitワークフロー
チームのgitワークフローで小さな問題に遭遇しました。
ユーザーストーリーの作業を開始するときに、開発ブランチから機能ブランチを作成します。ユーザーストーリーが完了すると、プルリクエストが作成され、別の開発者がコードレビューを完了します。次に、QAは機能ブランチで機能をテストします。
多くの場合、プルリクエストの作成からテストの終了まで、ブランチを開発するために新機能をマージするのに1日以上かかります。
次の機能に取り掛かったときに問題が発生します。これは、まだテスト中の前の機能に依存します。以前の機能がマージされて開発されていないため、開発から分岐できません。
その場合は、通常、開発するのではなく、他の詳細ブランチから機能ブランチを作成します。
このフローが受け入れられ、改善できるかどうか知りたいのですが。それともこれは単なるコミュニケーションの問題ですか？
プロセス自体の一部で問題が発生する可能性がありますが、そのワークフローは会社のプロセスに適しているようです。ワークフローを改善するために実行できることの1つは、開発intoを新しい機能ブランチにマージすることです。そうすれば、開発を他の変更とローカルに統合し、開発をより早く開始できます。
また、QAがプルリクエストごとに1日テストする場合、それらのプルリクエストは多少大きくなる可能性があります。ユーザーストーリーごとにいくつかの小さなプルリクエストを実行し、完了したユーザーストーリーをQAに渡すことを検討する場合があります。
全体的にプロセスは合理的であるように見えますが、製品の複雑さやチームの規模に応じて拡大するようには見えません。
developブランチから機能ブランチを作成するという考えは、良さそうです。この分岐モデルは、 gitflowモデル と一致しています。 developからの機能分岐を含む関連分岐モデルがいくつかありますが、masterとリリース分岐の使用方法は異なります。このタイプのアプローチは、リリースとデプロイへのアプローチにもよりますが、全体的にはうまくいきました。
機能ブランチでのテストが、テストしたい場所かどうかはわかりません。私は QAが同様の質問への回答でテストを実行する必要がある場所について書きました 。一般的に言えば、テストは2回行う必要があります。1回は機能ブランチで、追加した機能が意図したとおりに機能していることを確認し、1回は統合ブランチ（この場合はdevelop）で、システムが安定していることを確認します。残っている問題は、それぞれの場所で誰がテストを行い、どのようなテスト方法が使用されているかです。
機能を継続するために機能ブランチから分岐する必要がある場合がありますが、これは多くの場合、建築上の負債や作業を最良の方法で分解していないなど、他の何かの症状です。これはまれなイベントであり、定期的に発生するものではありません。
私が最も懸念しているのは、このプロセス全体での自動化テストの欠如です。 「自動テスト」とは、単体テストから機能テスト、受け入れテストまで、自動化されたプロセスで実行できるすべてのテストを指します。特にシステムが複雑になるにつれて、手動テストはコストがかかります。私が好むアプローチは、テストの自動化を導入し、プルリクエストとコードレビューの一部として少なくとも "happy-path" テストと回帰テストを含めることです。 。目標は、欠陥を早期に発見し、QA手動テストの負担を軽減することです。