12

優れた CI ビルド プロセスを構成するものは何ですか?

私たちは CI を使用していますが、展開する必要のある複数のサービスに依存しており、他のアプリもこれらに依存している可能性がある場合、本番環境への展開は現実的な CI の目標です。

優れた CI ビルド プロセスは、QA まで自動化され、そこから手動で行われる場合に十分なのか?

4

7 に答える 7

14

まあ「場合による」:)

CI システムを使用して、次のことを行います。

  1. ビルドと単体テスト
  2. 単一のボックスに展開し、統合テストとコード分析を実行します
  3. ラボ環境にデプロイする
  4. 製品のようなシステムで受け入れテストを実行する
  5. prod デプロイメントのコード ドロップに渡されるドロップ ビルド

これは、20 以上のサーバーにデプロイされた約 12 のサービスとデータベースのグリーンフィールド プロジェクトであり、他の 6 つの「外部」サービスにも依存していました。

CI ツールを使用して製品を本番環境にデプロイすることは、現実的な目標ですか? もう一度...「場合による」

なぜこれをしたいのですか？

  • プロセスがあれば、変更をより速く、より頻繁にロールバック (およびロールバック) できます。
  • ヒューマンエラーの可能性が少ない
  • 本番環境に移行する前にテスト環境で同じ展開戦略をテストし、問題を早期に発見できます

これに答える前に対処しなければならないいくつかの技術的な事柄:

  • あなたのシステムの稼働時間の要件は何ですか -- ダウンタイムが許されていますか、それとも 24 時間 365 日稼働している必要がありますか?
  • 人間の介入/承認を必要とする変更管理プロセスが導入されていますか?
  • デプロイが失敗した場合にコンポーネントが既知の良好な状態にロールバックできるほど、デプロイは十分に堅牢ですか?
  • システムは、1 つまたは複数のコンポーネントの展開が失敗した場合に、異なるバージョンのサービスまたはクライアントを処理するように設計されていますか?
  • プロセスには、コンポーネントが依存関係/クライアントの混合バージョンを処理できない部分的な展開を処理するスマートがありますか?
  • データベースの展開/アップグレードをどのように処理していますか?
  • 何か問題が発生したときにわかるように監視を行っていますか?

自動化と必要なツールの構築に関する最近の関連リンクをいくつか紹介します。

結局のところ、システムが複雑になればなるほど、すべてを自動化することは難しくなりますが、それは価値のある目標ではないという意味ではありません。直面する困難、説明しなければならない問題 (失敗は起こります)、インフラストラクチャーの構築における政治的課題 (製品機能の増加と比較して)。

ここに大きな秘密があります...技術的な課題は挑戦的ですが、不可能ではありません.政治的な課題は克服できないかもしれません. 開発時間であろうと、サードパーティ製ソリューションの購入であろうと、これに関するすべてに費用がかかります。では、本当に、1,000 ドル、1 万ドル、10 万ドル、または 100 万ドルのソリューションを構築できますか?

どのソリューションを選択する場合でも、最初に自動化が堅牢であることを確認し、次に完全であることを確認してください...つまり、本番環境に展開する脆弱なソリューションではなく、テスト環境に展開するための可能な限り堅牢なソリューションがあることを確認してください。

于 2008-09-19T17:09:44.160 に答える
4

CI は展開メカニズムとして意図されたものではありません。CI に QA/テスト サーバーへの自動展開を実行させて、ビルドのこれらの側面を確実に機能させるのは良いことですが、Cruise Control や Bamboo のような CI システムを展開の手段として使用することはありません。

CI は、コードベースを定期的に構築して、自動テストの実行、静的分析によるコードベースの検証、およびその性質のその他のチェックを自動化するためのものです。

于 2008-09-19T15:36:37.457 に答える
3

CIビルドの背後にある考え方を必ず理解してください。CIは継続的インテグレーションの略で、CIビルドは、開発者がコードをソース管理システムにチェックインするときに（または指定された間隔で）実行される使い捨てビルドであり、最新の変更によってコードベースが破損しないようにすることを目的としています。 （したがって、コードベースへの変更を継続的に統合するという考え）。

そのために、実際のビルドサーバープロセスに使用されるテクノロジーは、ビルド中に実際に行われるものと比較して、ほとんど無関係です。@pdavisが述べたように、CIビルドはコードベースをコンパイルし、コード分析（FxCop、StyleCop、Lintなど）を実行し、単体テストとコードカバレッジを実行し、コンセプトに影響を与えるその他のカスタム分析を実行する必要があります。 「成功した」または「失敗した」ビルドの

CIビルドを環境に自動的にデプロイすることは、実際にはビルドサーバーの制御下にはありません。そうは言っても、特定の条件（ビルドが正常に完了したなど）を検出したときにデプロイメントを処理するビルドサーバーで実行される別のプロジェクトをいつでも作成できますが、それは常に完全に独立したものとして実行する必要があります。

于 2008-09-19T15:50:08.860 に答える
2

私は本当に楽しみにしている仕事で新しいプロジェクトを始めています。私たちはまだ初期設計段階にあり、最近、論理システム アーキテクチャを完成させました。テスト環境とステージング環境用に新しいサーバーを注文し、Cruise Control ( http://cruisecontrol.sourceforge.net/ ) と MSBuild ( http://msdn2.microsoft. com/en-us/library/wea2sca5.aspx ) は基本的に ANT の改良版です。現在、Visual Studio 2005 のプロジェクト ファイルとソリューション ファイルはすべて MSBuild 形式になっているようです。Cruise Control は、Visual Source Safe からソースを自動的にプルし (OK、Subversion ではありませんが対処できます)、コンパイルし、fxCop を介して実行します (http://www.gotdotnet.com/Team/FxCop/ )、nUnit ( http://www.nunit.org/ )、nCover ( http://ncover.org/site/ )、および最後に Simian をリースしていません( http://www.redhillconsulting.com.au/products/simian/）。Cruise Control には、さまざまなツールからコンパイルされたすべての結果を表示するための非常に優れた Web サイト インターフェイスがあり、1 つのビルドから次のビルドへのコードの変更を表示することもできます。また、ビルド履歴ですべてのビルドを追跡します。テスト駆動型の開発を楽しみにしており、nUnit/nCover と組み合わせたこのタイプのアプローチは、変更をロールアウトする前に、何も壊れていないというかなり良いアイデアを提供してくれるはずだと考えています。プロジェクトが十分に進んだら、ある種の自動化されたユーザー インターフェイス テストを組み込む計画もあります。ツールによっては、ビルド サーバーにツールをインストールし、Cruise Control から呼び出すだけで済みます。甘い。

于 2008-09-19T15:37:55.067 に答える
2

優れた CI プロセスは、単体テストを完全またはほぼ完全にカバーします。単体テストでは、クラスとメソッドをテストします。対して、システムの複数の部分をテストする統合テストです。CI ビルドをセットアップするときは、ユニット テストを自動化します。そうすれば、CI ビルドを 1 日に複数回実行できます。2 時間ごとに実行するように設定しています。

1 日に 1 回実行されるビルドを長時間実行することができます。これらは他のサービスを使用し、統合テストを実行できます。

于 2008-09-19T15:38:55.300 に答える
1

私は、ThoughtWorks のプレゼンテーション (Cruise Control の作成者) を見ていましたが、彼らは実際にこの問題に取り組んでいました。彼らの答えは、NO 展開は複雑すぎてテストできないというものです。なんで？そうしないと、顧客がテスターに​​なってしまいます。

展開構造が複雑な場合は、視覚化サーバーをセットアップします。対話する必要があるすべてのシステムのふりをしてもらいます。クリーンなイメージにリセットできるため、常に既知の良好な状態で開始できます。

最初の質問に答えると、良いプロセスとは、リポジトリと開発者の間のコミュニケーションを可能にするプロセスです。リポジトリが悪い状態 (コンパイルされていないコード、失敗したテストなど) にある場合、開発者はできるだけ早くそれを認識して修正できるようにします。

于 2008-09-19T15:39:44.017 に答える
1

バグの発見が遅ければ遅いほど、修正にかかる費用は高くなります。そのため、バグはできるだけ早く発見する必要があります。これが CI の背後にある動機です。

優れた CI は、できるだけ多くのバグを確実にキャッチする必要があります。アプリケーション全体は、コード (多くの場合、複数の言語)、データベース スキーマ、展開ファイルなどで構成されます。これらのいずれかにエラーがあるとバグが発生する可能性があるため、CI はできるだけ多くのエラーを実行する必要があります。

CI は、適切な QA 規律に取って代わるものではありません。また、CI は、プロジェクトの初日に非常に包括的である必要はありません。最初に基本的なコンパイルと単体テストを行う単純な CI プロセスから始めることができます。QA でより多くの種類のバグを発見したら、CI プロセスを適応させて、それらのバグの今後の発生を捕捉するようにする必要があります。また、コードベース全体で一貫したコーディングと設計の理想を実装できるように、静的コード分析チェックを含めることもできます。

于 2008-09-19T16:17:46.143 に答える