継続的インテグレーションの簡単な説明
継続的インテグレーションをどのように定義し、CIサーバーにはどの特定のコンポーネントが含まれていますか？
継続的インテグレーションとは何かをマーケティング部門の誰かに説明したいと思います。彼らはソース管理を理解しています。つまり、Subversionを使用しています。しかし、CIとは何かを適切に説明したいと思います。 Wikipedia Article がそれを適切に定義することは決してなく、 Martin Fowlerの記事 は以下を提供するだけです。
継続的インテグレーションは、チームのメンバーが頻繁に作業を統合するソフトウェア開発プラクティスです。通常、各人が少なくとも毎日統合し、1日に複数の統合が行われます。各統合は、自動ビルド（テストを含む）によって検証され、統合エラーを可能な限り迅速に検出します。
更新：この画像を送信しましたが、もっと簡単な画像が見つかりませんでした。
更新2：マーケティング担当者からのフィードバック（3つの質問があったとき）：
私は実際には3つの答えすべてが好きです–理由はさまざまです。感謝の気持ちを込めてログインしたい！
明らかに彼はできません-だから彼に代わって感謝します:)
更新3：Wikipediaの記事を見ると、 原則 が含まれていることがわかりました。見出しはかなり良いリストです：
- コードリポジトリを維持する
- ビルドを自動化する
- ビルドをセルフテストする
- 全員が毎日ベースラインに取り組みます
- （ベースラインへの）すべてのコミットを構築する必要があります
- ビルドを高速に保つ
- 本番環境のクローンでテストする
- 最新の成果物を簡単に入手できます
- 誰もが最新のビルドの結果を見ることができます
- 導入を自動化
誰かがソフトウェア製品を構成するファイルを変更し、それらをチェックインしようとする場合（つまり、メイン製品コードへの変更をintegrateしようとする場合）、ソフトウェア製品が引き続き正常に構築できます。
通常、CIサーバーと呼ばれる外部システムがあり、定期的またはすべての変更時に、バージョン管理からソースファイルを取得し、製品のビルド（コンパイル/テスト/パッケージ）を試みます。 CIサーバーが正常にビルドできる場合、変更は正常に統合されています。
また、CIサーバーは、ビルドが失敗または成功した場合にブロードキャストできる必要があります。そのため、Jenkins（今日最も使用されているCIサーバーの1つ）のようなシステムには、電子メール/テキスト、およびダッシュボードのようなWebインターフェースを送信する方法があります。現在のビルドと過去のビルド、コードをチェックインしたユーザー、問題が発生したときなどに関する一連の情報（上の画像では、これはフィードバックメカニズム）
CIは重要です。これにより、継続的に製品が機能するようになります。これは、ソフトウェア製品に取り組んでいるすべての開発者と、QAなどのソフトウェア製品の毎日のリリースにアクセスしたいすべての人々にとって重要です。
CIのしくみは重要ではありませんが、CIがあなたの新しいリリースで何を意味するかは重要ではありません。ソフトウェア。
CIは理想的には、新しい潜在的にリリース可能なバージョンを毎日作成し、顧客に提示または販売する準備ができて、いくつかの新しい機能、機能、またはバグ修正を追加できることを意味します。これは、新しいバージョンを毎日配信する必要があることを意味するわけではありませんが、必要に応じて配信できます。
たとえば、ソフトウェアの「2015」バージョンで正式にリリースされる予定の新しい機能セットがあり、その機能セットの一部がすでにコーディングされて統合されている場合、マーケティング担当者はあなたの現在のバージョンを使用できます。ソフトウェアとそれを（多かれ少なかれ安全に）次の会議で2013年に開催します。CIなしでは、チームに計画外のコードのフリーズを依頼する必要があり、すべてのチームメンバーは自分が取り組んでいる中途半端な機能を製品では、十分な自動テストの準備ができていない可能性があり、会議で何が起こるかを推測します-2015erリリースの「アルファ版」は、特に新機能がデモされたときに、クラッシュするリスクがはるかに高くなります。
私たちが以前何をしていたのかを知らなければ、CIが何であるかを知ることはできません。 3つの部分からなるシステムを想像してください。データを収集してデータベースに配置するUIがあります。データベースからレポートを作成するレポートシステムがあります。また、データベースを監視し、特定の基準が満たされた場合に電子メールアラートを送信するサーバーのようなものがあります。
ずっと前に、これは次のように書かれるでしょう：
- データベースのスキーマと要件について同意します。理由がすぐにわかるので、完璧にする必要があるため、これには数週間かかります。
- 3人の開発者、または3人の独立した開発者チームを3つの部分に割り当てます
- 各開発者は自分の作品に取り組み、数週間または数か月間、独自のデータベースコピーを使用して作品をテストします。
この間、開発者はお互いのコードを実行したり、他の誰かのコードによって作成されたデータベースのバージョンを使用したりすることはありませんでした。レポート作成者は、一連のサンプルデータを手動で追加します。アラートライターは、レポートイベントをシミュレートしたレコードを手動で追加します。また、GUIの作成者はデータベースを調べて、GUIが追加したものを確認します。やがて、開発者は、インデックスを指定しなかったり、フィールド長が短すぎたりするなど、仕様が間違っていることに気づき、バージョンでそれを「修正」しました。彼らは他の人にそれを実行するかもしれないと言うかもしれませんが、通常これらのことは後でリストに載ります。
3つの部分すべてが完全にコード化され、開発者によってテストされ、場合によってはユーザーによってテスト（レポート、画面、または電子メールアラートが表示される）されると、「統合」フェーズになります。これはしばしば数か月で予算が組まれましたが、それでも解決します。開発者1によるフィールド長の変更はここで発見され、開発者2と3がコードを大幅に変更し、場合によってはUIも変更する必要があります。その余分なインデックスは、独自の大混乱をもたらします。等々。開発者の1人がユーザーからフィールドを追加するように言われ、そうした場合、今度は他の2人もフィールドを追加する必要がありました。
このフェーズは非常に痛く、予測することはほとんど不可能でした。それで人々は「もっと頻繁に統合しなければならない」と言い始めました。 「私たちは最初から一緒に働かなければなりません。」 「私たちの1人が変更リクエストを出したとき[そのように話し合いました]、他の人はそれについて知る必要があります。」一部のチームは、個別に作業を継続しながら、以前に統合テストを開始しました。そして、いくつかのチームは最初からお互いのコードを使用し、常に出力し始めました。そしてそれが継続的インテグレーションとなりました。
私はその最初の話を誇張していると思うかもしれません。私は一度会社に勤めましたが、次の欠陥に悩まされているコードをチェックインするために私の連絡先が私を噛んでしまいました：
- 彼が作業していない画面には、まだ何もしないボタンがありました
- 画面デザインにサインオフしたユーザーはいませんでした（正確な色とフォント、画面の存在、その機能、および300ページ仕様にあったボタン）。
それが完了するまで、あなたはソース管理にものを入れないことが彼の意見でした。彼は通常、1年に1〜2回チェックインしました。私たちは哲学に少し違いがありました:-)
また、データベースのような共有リソースの周りでチームが切断されると信じがたい場合は、同じアプローチがコードに取られたとは信じられないでしょう（しかし、本当です）。あなたは私が呼び出すことができる関数を書くつもりですか？それは素晴らしいことです。先に進んでそれを実行してください。それまでの間、必要なものだけをハードコーディングします。数か月後、コードを "統合"してAPIを呼び出し、nullを渡すと爆破することがわかります。nullを返すと爆破します（それは多くのことを行います）、大きすぎるものを返します私にとっては、うるう年など、何千にも対応できません。独立して作業し、その後統合フェーズを持つことは正常でした。今、それは狂気のように聞こえます。