継続的インテグレーションの簡単な説明

継続的インテグレーションをどのように定義し、CIサーバーにはどのような特定のコンポーネントが含まれますか？

マーケティング部門の誰かに継続的インテグレーションとは何かを説明したいと思います。彼らはソース管理を理解しています-つまり、Subversionを使用しています。しかし、私は彼らにCIが何であるかを適切に説明したいと思います。ウィキペディアの記事は、それを適切に定義することはありません、Martin Fowler氏の記事は、のみ基本的に「統合」のあいまいな説明に続いてトートロジーである、次のようになります：

継続的インテグレーションは、チームのメンバーが頻繁に作業を統合するソフトウェア開発プラクティスです。通常、各ユーザーは少なくとも毎日統合し、1日に複数の統合を行います。統合エラーを可能な限り迅速に検出するために、各統合は自動ビルド（テストを含む）によって検証されます。

更新：私は彼らにこの画像を送った、私はより簡単なものを見つけることができなかった。

更新2：マーケティングチャップからフィードバック（質問が3つあったとき）：

私は実際には3つの回答すべてが好きです。理由はさまざまです。それらすべてに感謝するためだけにログインしたい気がします！

明らかに彼はできません-だから彼に代わってありがとう:)

更新3：ウィキペディアの記事を見て、見出しだけを取り上げると非常に良いリストである原則が含まれていることに気付きました。

1. コードリポジトリを維持する
2. ビルドを自動化する
3. ビルドを自己テストする
4. 誰もが毎日ベースラインにコミットします
5. （ベースラインへの）すべてのコミットを構築する必要があります
6. ビルドを高速に保つ
7. 実稼働環境のクローンでテストする
8. 最新の成果物を簡単に入手できるようにする
9. 誰でも最新のビルドの結果を見ることができます
10. 展開を自動化する

誰かがソフトウェア製品を構成するファイルを変更してからチェックインしようとすると（言い換えれば、変更をメイン製品コードに統合しようとすると）、ソフトウェア製品が引き続き正常にビルドできることを確認する必要があります。

通常、CIサーバーと呼ばれる外部システムがあり、定期的または変更ごとに、バージョン管理からソースファイルを取得し、製品（コンパイル/テスト/パッケージ）のビルドを試みます。CIサーバーがビルドを正常に実行できる場合、変更は正常に統合されています。

ビルドが失敗または成功した場合、CIサーバーもブロードキャストできる必要があるため、Jenkins（現在最も使用されているCIサーバーの1つ）などのシステムには、電子メール/テキストとダッシュボードのようなWebインターフェイスを現在および過去のビルド、コードをチェックインした人、問題が発生した日時などに関する情報の束（上記の画像では、これがフィードバックメカニズムになります）

CIが重要なのは、それが継続的に機能する製品を確保するためです。これは、ソフトウェア製品に取り組んでいるすべての開発者と、QAなどのソフトウェア製品の毎日のリリースにアクセスしたいすべての人々にとって重要です。

あなたのマーケティング部門にとって、CIがどのように機能するかは重要ではありませんが、ソフトウェアの新しいリリースにとってCIが意味することです。

CIは、理想的には、リリース可能なソフトウェアの新しいバージョンを毎日作成し、顧客に提示または販売する準備を整え、新しい機能、機能、またはバグ修正を追加できることを意味します。これは、新しいバージョンを毎日提供する必要があるという意味ではありませんが、必要に応じて提供できます。

たとえば、ソフトウェアの「2015」バージョン用に正式にリリースされる予定の新しい機能セットがあり、その機能セットの一部がすでにコード化され統合されている場合、マーケティング担当者は現在のバージョンを使用できますCIがなければ、チームは計画外のコードフリーズをチームに依頼する必要がありました。すべてのチームメンバーは、自分が取り組んでいる中途半端な機能を統合する必要がありました。製品、彼らは十分な自動テストの準備ができていない可能性があり、会議で何が起こるかを推測-2015erリリースの「アルファ版」は、特に新しい機能が実証されている場合、クラッシュするリスクがはるかに高くなります。

私たちが何をしていたかを知らなければ、CIが何であるかを知ることはできません。3つの部分からなるシステムを想像してください。データを収集してデータベースに入れるUIがあります。データベースからレポートを作成するレポートシステムがあります。また、データベースを監視し、特定の条件が満たされた場合に電子メールアラートを送信するサーバーがあります。

昔は、これは次のように書かれていました。

1. データベースのスキーマと要件に同意します-すぐに理由がわかるように完璧でなければならないため、これには数週間かかります
2. 3つの開発者、または3つの独立した開発者チームを3つのピースに割り当てます
3. 各開発者は自分の作品に取り組み、数週間または数か月間、独自のデータベースコピーを使用して作品をテストします。

この間、開発者はお互いのコードを実行したり、他の人のコードによって作成されたデータベースのバージョンを使用しようとはしませんでした。レポート作成者は、大量のサンプルデータを手で追加するだけです。アラートライターは、レポートイベントをシミュレートしたレコードを手で追加します。そして、GUI作成者はデータベースを見て、GUIが追加した内容を確認します。時間が経つにつれて、開発者は、インデックスを指定しない、フィールド長が短すぎるなど、何らかの方法で仕様が間違っていることに気付き、バージョンでそれを「修正」しました。彼らは他の人に伝えるかもしれません、誰がそれに基づいて行動するかもしれませんが、通常これらのことは後でリストに載るでしょう。

3つの部分すべてが完全にコーディングされ、開発者によってテストされ、場合によってはユーザー（テスト、画面、または電子メールアラートを表示）によってもテストされると、「統合」フェーズになります。これは多くの場合、数か月で予算化されましたが、それでもまだ行き渡っています。dev 1によるそのフィールドの長さの変化はここで発見され、dev 2と3が大きなコード変更とおそらくUI変更も行う必要があります。その余分なインデックスはそれ自身の大混乱をもたらすでしょう。等々。開発者の1人がユーザーからフィールドを追加するように指示された場合、他の2人もフィールドを追加する必要があります。

この段階はひどく痛みを伴い、予測することはほとんど不可能でした。そのため、人々は「もっと頻繁に統合する必要がある」と言い始めました。「最初から一緒に仕事をしなければなりません。」「私たちの1人が変更要求を提起するとき（それが私たちの話し方です）、他の人はそれについて知る必要があります。」一部のチームは、個別に作業を続けながら、以前に統合テストを開始しました。また、一部のチームは、最初からお互いのコードを使用し、常に出力し始めました。そして、それが継続的インテグレーションになりました。

あなたは私がその最初の物語を誇張していると思うかもしれません。ある会社で仕事をしたことがありますが、次の欠陥に悩まされていたコードをチェックインするために連絡先が私をかみ砕きました。

• 彼が取り組んでいない画面にはまだ何もしないボタンがありました
• 画面デザインでサインオフしたユーザーはいません（正確な色とフォント、画面の存在、その機能、300ページ仕様にあったボタン）。

それが完了するまでソース管理に物を入れないという彼の意見でした。彼は通常、1年に1つまたは2つのチェックインを行いました。少し哲学的な違いがありました:-)

また、データベースのような共有リソースの周りでチームが切断されると信じるのが難しいと感じた場合、コードに対して同じアプローチが取られたとは本当に信じられません（しかし本当です）。あなたは私が呼び出すことができる関数を書くつもりですか？それは素晴らしい、先に行って、それを行う、私はちょうど私がその間に必要なものをハードコーディングします。数ヶ月後、コードを「統合」してAPIを呼び出します。nullを渡すと爆破し、nullを返すと爆破することを発見します（そして、それは多くのことを行います）。私にとっては、うるう年や他の何千ものものを扱うことはできません。独立して作業し、その後統合フェーズを持つことは正常でした。今では狂気のように聞こえます。