アジャイル開発デプロイメントプロセス。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 /ビジネステスト
• バグ修正（トップに戻る）
• ブランチを展開するためにマージする
• 展開する

単一のブランチで作業する人もいますが、手動テストを行う場合は難しくなります。私が遭遇したほとんどの人は、単一のトランクからも機能するものはコミット時にデプロイできると想定して動作しますが、何か小さなことをしている、または大量の自動テストを行っている、またはこの会話の「デプロイ」を検討していますテストサーバーへのビルドであり、テストサーバーと本番環境の間で発生するQAのプロセスは個別に処理されます。

同じ機能ブランチの自動受け入れテストがあります。リリース候補を作成すると、機能が合格するかどうかを確認するために実行した自動テストが含まれます。また、リリース候補をテストします。すべてが合格したら、マスターにマージすることで昇格します。

このプロセスの詳細はこちら：

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

コメントもチェックアウトしてください。

お役に立てれば、

アダム

原則として、コードが完全になる前にコミットを待つことは、バージョン管理システムの利点を取り戻す時間の半分です。（詳細な説明がなければ、VCSへの複数のチェックインが許可されていない限り、自分の作業を元に戻す方法はないと思います！）したがって、習慣として、常に（SVNのブランチ内で）チェックインを続けるように依頼します。または、GITの場合はローカルコミットにすることもできます）。実際には、より良いです。

ただし、すべてが実行およびテストされているように見えるポイントに到達すると、それをリリースと呼び、トランクとマージされます。基本的に、QA HEADはブランチので新しいチェックアウトを行うことでRCを認定できます。オーケーである場合、トランクにマージされます。

したがって、基本的にはタスクブランチまたはプライベートブランチの概念を使用するので、人々は必要なだけチェックインすることができます。同時に、トランクはチェックインの破損から比較的解放されています。