スクラムと継続的インテグレーションによるソフトウェア開発のための優れたワークフロー
回答:
あなたはそこにいくつかの方法がありますが、私はあなたの図をいくらか拡大します：
基本的に（バージョン管理で許可されている場合、つまりhg / gitを使用している場合）、開発者と開発者のペアごとに、作業中の単一のユーザーストーリーを含む独自の「個人用」ブランチが必要です。機能を完了すると、中央のブランチである「リリース」ブランチにプッシュする必要があります。この時点で、開発者が次に作業を行うために新しいブランチを取得する必要があります。元の機能ブランチはそのままにしておく必要があります。そのため、必要な変更は分離して行うことができます（これは常に適用できるわけではありませんが、良い出発点です）。開発者が古い機能ブランチで作業を再開する前に、最新のリリースブランチを使用して、奇妙なマージの問題を回避する必要があります。
この時点で、「リリース」ブランチの形で可能なリリース候補があり、CIプロセスを実行する準備ができています（そのブランチでは、明らかに各開発者ブランチでこれを行うことができますが、これは大規模な開発チームでは、CIサーバーが散らかってしまうことはほとんどありません）。これは一定のプロセス（これが理想的なケースであり、「リリース」ブランチが変更されるたびにCIを実行することが理想的です）、または夜間に行われる場合があります。
この時点で、ビルドを実行し、CIサーバーから実行可能なビルドアーティファクト（つまり、実行可能な展開が可能なもの）を取得します。動的言語を使用している場合は、この手順をスキップできます！構築したら、システム内のすべての自動テストの基盤であるユニットテストを実行します。それらは迅速である可能性が高く（CIの重要な点は開発とテストの間のフィードバックループを短縮することであるため）、展開する必要はほとんどありません。合格した場合は、アプリケーションをテストサーバーに自動的に展開し（可能な場合）、利用可能な統合テストを実行します。統合テストは、自動化されたUIテスト、BDDテスト、または単体テストフレームワーク（つまり「ユニット」
この時点までに、ビルドが実行可能かどうかをかなり包括的に示す必要があります。私が通常「リリース」ブランチでセットアップする最後のステップは、リリース候補をテストサーバーに自動的に展開することです。これにより、QA部門は手動のスモークテストを実行できます（これは、テストサイクルの混乱を避けるため）。これは、ビルドが実際のリリースに本当に適しているかどうかを簡単に人間に示すだけです。テストパックが包括的でない場合は見逃しがちであり、100％のテストカバレッジであっても、見逃すことは簡単です。 't（するべきではありません）自動的にテストします（画像の位置のずれ、スペルミスなど）。
これは実際には継続的インテグレーションと継続的デプロイの組み合わせですが、アジャイルの焦点はリーンコーディングと自動化されたテストに一流のプロセスとして焦点を当てていることを考えると、できるだけ包括的なアプローチを目指したいと思います。
私が概説したプロセスは理想的なケースのシナリオであり、その一部を放棄する理由は数多くあります（たとえば、開発者ブランチはSVNでは単純に実行不可能です）が、できるだけ多くを目指したい。
スクラムスプリントサイクルがこれにどのように適合するかについては、理想的には、リリースをできるだけ頻繁に行い、スプリントの最後までリリースを残さないでください。機能（および全体としてビルド）生産への移行が実行可能であることは、プロダクトオーナーへのフィードバックループを短縮するための重要な手法です。
概念的にははい。ダイアグラムは、次のような重要なポイントを多く捉えていません。
- 単体テスト
- 増分コミット
- ステージングは頻繁に展開されますが、本番は通常展開されません。
ダイアグラムにもっと広いシステムを描くこともできます。次の要素を追加することを検討します。
開発者に提供されるシステムへの入力を表示します。それらを要件、バグ修正、ストーリーなどと呼びます。ただし、現在のワークフローでは、視聴者がこれらの入力がどのように挿入されるかを知っていると想定しています。
ワークフローに沿ってコントロールポイントを表示します。誰/何がトランク/メイン/リリースブランチ/などに変更を許可するかを決定しますか？どのコードツリー/プロジェクトがCIS上で構築されていますか？ビルドが壊れているかどうかを確認するチェックポイントはありますか？CISからステージング/プロダクションにリリースするのは誰ですか？
コントロールポイントに関連するのは、分岐方法とは何か、そしてこのワークフローにどのように適合するかを識別することです。
テストチームはありますか？いつ関与または通知されますか？CISで自動テストが実行されていますか？破損はどのようにシステムにフィードバックされますか？
このワークフローを、決定点と入力を含む従来のフローチャートにどのようにマッピングするかを検討してください。ワークフローを適切に説明するために必要なすべての高レベルのタッチポイントをキャプチャしましたか？
あなたの元の質問は比較を試みていると思いますが、どの側面を比較しようとしているのかはわかりません。継続的インテグレーションには、他のSDLCモデルと同様に決定ポイントがありますが、プロセスの異なるポイントにある場合があります。
「開発自動化」という用語を使用して、すべての自動化されたビルド、ドキュメント生成、テスト、パフォーマンス測定、展開アクティビティを網羅しています。
したがって、「開発自動化サーバー」には、継続的な統合サーバーよりも似ていますが、多少広い権限があります。
CIサーバーでの追加の構成を必要とせずに、プライベートブランチと中央開発トランクの両方を自動化できるポストコミットフックによって駆動される開発自動化スクリプトを使用することを好みます。（これにより、私が知っている市販のCIサーバーGUIのほとんどを使用できなくなります）。
コミット後スクリプトは、ブランチ自体のコンテンツに基づいて実行する自動化アクティビティを決定します。ブランチ内の固定された場所にあるコミット後の構成ファイルを読み取るか、リポジトリ内のブランチへのパスのコンポーネントとして特定の単語を検出します（Svnを使用）。
（これはHgよりもSvnで設定する方が簡単です）。
このアプローチにより、開発チームはワークフローの編成方法についてより柔軟になり、CIは最小限（ゼロに近い）の管理オーバーヘッドでブランチの開発をサポートできます。
asp.netには継続的インテグレーションに関する有益な一連の投稿があり、役に立つと思うかもしれません。それは、あなたがやっているように見えるものに適合するかなりの根拠とワークフローをカバーしています。
ダイアグラムでは、CIサーバーで行われた作業（ユニットテスト、コードカバレッジとその他のメトリック、統合テストまたはナイトリービルド）については言及していませんが、それはすべて「継続的統合サーバー」ステージでカバーされていると思います。しかし、CIボックスが中央リポジトリにプッシュバックする理由は明確ではありませんか？明らかにコードを取得する必要がありますが、なぜそれを送り返す必要があるのでしょうか？
CIはさまざまな分野で推奨されているプラクティスの1つであり、スクラム（またはXP）に固有のものではありませんが、実際には、滝などの非アジャイル（ウェットアジャイル？） 。私にとっての主な利点は、タイトなフィードバックループです。コミットしたコードが残りのコードベースで機能するかどうかは、すぐにわかります。スプリントで作業していて、毎日のスタンドアップを持っている場合、ステータスを参照できるか、CIサーバーで昨夜のメトリックを構築することは間違いなくプラスであり、人々を集中させるのに役立ちます。プロダクトオーナーがビルドのステータス（ビルドプロジェクトのステータスを表示する共有エリアの大きなモニター）を確認できる場合、フィードバックループは本当に強化されています。開発チームが頻繁に（1日に1回以上、理想的には1時間に1回以上）コミットしている場合、解決に時間がかかる統合の問題に遭遇する可能性は減少しますが、そうすることは明らかです必要なあらゆる手段を講じることができます。たとえば、壊れたビルドに対処するために全員が停止します。実際には、頻繁に統合するかどうかを判断するのに数分以上かかる失敗したビルドの多くはおそらくヒットしません。
リソース/ネットワークに応じて、異なるエンドサーバーの追加を検討できます。レポジトリへのコミットによってトリガーされるCIビルドがあり、すべてのテストをビルドしてパスすると、開発サーバーにデプロイされるので、開発者はそれがうまく動作することを確認できます（ここにセレンや他のUIテストを含めることができますか？ ）。ただし、すべてのコミットが安定したビルドではないため、ステージングサーバーへのビルドをトリガーするには、ビルド（デプロイ）するリビジョン（mercurialを使用）にタグを付ける必要があります。これも、特定の鬼ごっこ。実稼働に移行するのは手動プロセスです。ビルドを強制するのと同じくらい簡単にすることができます。どのリビジョン/ビルドを使用するかを知っているので、ただし、リビジョンに適切にタグを付けると、CIサーバーは正しいバージョンをチェックアウトし、必要な処理を実行できます。MS Deployを使用して変更を本番サーバーに同期するか、パッケージ化して、管理者が手動で展開する準備ができている場所にzipを配置することができます。
バージョンを上げるだけでなく、障害に対処してバージョンを下げる方法も検討する必要があります。うまく行かないことを願っていますが、サーバーに何らかの変更が加えられる可能性があります。これは、UATで機能するものが運用環境で機能しないため、承認済みバージョンをリリースすると失敗することを意味します...バグ、コードの追加、コミット、テスト、プロダクションへの展開による修正...または自動化されたリリースのテストをさらにプロダクションにラップし、失敗した場合は自動的にロールバックできます。
CruiseControl.Netはxmlを使用してビルドを構成し、TeamCityはウィザードを使用します。チームの専門家を避けたい場合は、xml構成の複雑さを念頭に置く必要があります。
まず、警告：スクラムはかなり厳密な方法論です。私はスクラム、またはスクラムのようなアプローチを使用しようとしたいくつかの組織で働いてきましたが、どちらも完全に規律全体を使用することに本当に近づきませんでした。私の経験から、私はアジャイル愛好家ですが、（嫌がる）スクラムに懐疑的です。
私が理解しているように、スクラムと他のアジャイルメソッドには2つの主な目的があります。
- 1つは、リスクを管理し、リスクを継続的に発見するための明示的なメカニズムを提供することです。
- 2つ目は、利害関係者とのコミュニケーション、要件の発見、要件管理のための構造化されたメカニズムを提供することです。
最初の（リスク管理）目的は、反復的な開発によって達成されます。ミスを犯してすぐにレッスンを学習し、チームがリスクを軽減するための理解と知的能力を構築し、低リスクの「苦情」ソリューションをすでにバッグに入れた状態でリスクを低減するソリューションに移行できるようにします。
継続的インテグレーションを含む開発自動化は、このアプローチの成功において最も重要な要素です。リスク発見とレッスン学習は、迅速で、摩擦がなく、交絡する社会的要因のないものでなければなりません。（他の人間よりも自分が間違っていることを伝えるマシンであれば、エゴは学習の邪魔になるだけです。）
おそらくおわかりのように、私はテスト駆動開発のファンでもあります。:-)
2番目の目的は、開発の自動化ではなく、ヒューマンファクターに関連しています。ビジネスのフロントエンドからの賛同を必要とするため、実装が難しくなります。
ここでは、自動化されたドキュメントと進捗レポートを使用して開発チーム外の利害関係者が進捗状況を継続的に更新し、ビルドステータスとテストスイートの合格/失敗を示す情報ラジエーターを使用して進捗状況を伝えることができるという点で、開発オートメーションに役割を持たせることができます機能開発において、（できれば）スクラムコミュニケーションプロセスの採用を支援します。
したがって、要約すると：
質問の説明に使用した図は、プロセスの一部のみをキャプチャしています。アジャイル/スクラムとCIを勉強したい場合、プロセスのより広範な社会的要因と人的要因の側面を考慮することが重要であると主張します。
私がいつもやるのと同じドラムを叩いて終わらせなければならない。現実のプロジェクトにアジャイルプロセスを実装しようとしている場合、成功する可能性を最も予測するのは、展開されている自動化のレベルです。摩擦を減らし、速度を上げ、成功への道を開きます。