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