アジャイル開発デプロイメントプロセス。 QAとビジネスオーナーはどこでテストしますか？
私は最近、SVNまたはGITを使用したさまざまなWebアプリケーションの展開プロセスについて、現在作業している場所での展開方法を再設計するために、多くのことを読んでいます。
アジャイルの多くのフレーバーの方法と同様に、マスターまたはトランクにコミットしたものはすべて本番環境で使用できると想定されています。 GitHubとEtsyの両方 http://codeascraft.etsy.com/2010/05/20/quantum-of-deployment/ 彼らはこれに基づいて動作すると言っています（Etsyには実際にはステージング環境があります） 。
このプロセスは、すべての単体テストとCIテストが実行されていることを前提としています。ローカルおよびCIでテストを実行してから、トランクにコミットします。 SO、この時点であなたのコードは技術的にサウンドです。
あなたのコードは技術的には正しいかもしれませんが、ユーザー/機能テストは、特にフロントエンドテストに関して、より多くのバグを発掘するかもしれません。
私の質問はこれです。 QAおよびビジネスオーナーは、実装した機能の変更をどこでテストしますか？トランクにコミットする前のローカル開発マシン、またはQA /ステージングマシン上で？
トランクから実行されるステージングマシンがあり、トランクにコミットされたすべてのコードが本番環境で使用できると想定している場合...ええと、どの時点で、コードはサインオフされ、技術とビジネスの両方から本番環境に移行するのに適しています。視点？ステージングマシンが1つしかなく、多くの開発者がいて、コードがQAされる場合、多くの開発者の変更がサインオフを待機している可能性があるため、トランクからどのように展開できますか。
他の人がこれにどのように取り組んだか聞いてみたいと思いますか？
良くも悪くも、私は通常、これがブランチベースに対してテストが行われる場所で行われ、ビジネスサインオフがチェックポイントがデプロイメインにマージされることになります。
これは、別の「デプロイ済み」ブランチを持つ「メイン」での開発、またはメインが「デプロイ済み」である開発「機能」ブランチの両方で行われるのを見てきました。
ワークフローは次のようになります。
- 何かをコーディングする
- ローカルテストを実行する
- 作業ブランチにチェックイン
- （オプション）ビルドサーバーがAntテストをビルドする
- QA /ビジネステスト
- バグ修正（トップに戻る）
- ブランチを展開するためにマージする
- 展開する
単一のブランチで作業する人もいますが、手動テストを行う場合は難しくなります。私が遭遇したほとんどの人は、単一のトランクからも機能するコミット時に展開できるものは何か小さなことをしている、または膨大な量の自動テストを行っているという前提で機能していますORそれらこの会話の「デプロイ」はテストサーバーへのビルドであると考えてください。テストサーバーと本番環境の間で発生するQAのプロセスは個別に処理されます。
同じ機能ブランチの自動受け入れテストがあります。リリース候補を作成すると、機能が合格するかどうかを確認するために実行した自動テストが含まれます。また、リリース候補をテストします。すべてが合格したら、マスターにマージすることで昇格します。
このプロセスの詳細はこちら：
https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
コメントもチェックアウトしてください。
お役に立てれば、
アダム
原則として、コードが完全になる前のcommit to wait commitは、バージョン管理システムの利点を取り戻す時間の半分です。 （詳細な説明がなければ、VCSへの複数のチェックインが許可されていない限り、自分の作業を元に戻す方法はないと思います！）そのため、習慣として、（SVNのブランチ内で）チェックインを続けるよう常に求めています。または、GITの場合はローカルコミットにすることもできます）。実際には、より良いです。
ただし、すべての出現が実行およびテストされるポイントに到達すると、それをリリースと呼び、-thenはトランクとマージされます。基本的に、QAはブランチのHEADをチェックすることでRCを認定できます。彼/彼女がそれを持っている場合、同じことがトランクにマージされます。
したがって、基本的にはタスクブランチまたはプライベートブランチの概念を使用するため、人々は必要なだけチェックインすることができます。同時に、トランクは比較的無料から壊れたチェックインです。