複数のアジャイルチームでのバージョン管理(再)
以前にも書いたが、チームが自律的で各コードラインポリシーとそのポリシーを壊さないようにするためのルールに従って作業できるなら、このやり方はうまくいく。自分たちの環境にもっと適合するようにカスタマイズすることだってできるだろう。
ただ、記事中の回帰テストについては誤解を生むかもしれないので、少し僕なりの考えを書いてみたいと思う。
回帰テストには、同時開発時の他のチームの変更分のテストは必ずしも含まれている必要はない。ここでの回帰テストのスコープは「自分たちのチームの変更が既存の全ての回帰テストを通過することで何も壊していないことを保証する」こと。各開発チームの変更の統合については、開発ブランチからトランクに公開された時点で、すべての回帰テストも公開されるので、ここでCIがぶん回っていれば問題なし。
開発ブランチでは、以下のような2本立てのCIサイクルを回すとよいだろう。
- 夜間ビルド
回帰テストは自動化されたテストが基本。これには機能テストツール(WebアプリならSeleniumのようなWebテスティングツール)を使用する。自動化された回帰テストには、シナリオテスト、QAサイクルで報告されたバグまたは顧客やユーザーから報告されたバグを再現するテスト（デバッギングテスト）を含める。このような回帰テストには長い時間を要するので、全ての自動化された単体テストも含め、CIサーバーで夜間ビルドをスケジューリングして実行する。
- 日次ビルド
日次ビルド（チェックイン毎にビルドされる）時には、システムの要となるテスト（全ての単体テストのサブセットとなる場合が多い）をスモークテストとして実行することで、ビルドの結果に対するフィードバック速度を確保する。
また、手動のテストは、リリース作業で実施するといいだろう。リリースサブチームは、リリースブランチからステージング環境にリリース予定のソフトウェアを公開する。QAチームは、このステージング環境のソフトウェアに対して手動でのテストを実行する。リリースブランチはこの期間中は凍結される。QAチームの作業が完了すると、リリースサブチームはリリースブランチを再度アクティブにして、QAチームから報告されたバグに対するデバッギングテストを作成してからバグ対応を実施する。
あと、最後にひとつだけ。
むやみにブランチは増やすべからず。
そのコードラインの目的が明確ではないか、コードラインポリシーが十分にシンプルでないのなら、ブランチの必要性を疑うべし。
＃あとで書いた
実は、この内容はNAnduさんの記事にコメント書こうとしたんだけど、書けなかったのでこっちに書いているうちに長くなっちゃったものです(w
