Travis CIはアイデアとして始まり、当時は多少理想的でさえありました。プロジェクトの立ち上げ当時、オープンソースコミュニティにはまだ使える継続的インテグレーションシステムがありませんでした。
Githubがオープンソースコラボレーションプラットフォームとしてますます認知されるにつれ、オープンソースプロジェクトが常に安定した健全な状態にあることを保証するために、貢献されたコードを継続的にテストできるサービスが非常に必要とされています。
Travis CIは2011年初めにスタートし、すぐにトライアル顧客を獲得しました。2011年の夏までには、1日あたり700のビルドが行われるようになりました。これらのビルドはすべて単一のビルドサーバーで行われ、Travis CI は現在も Travis CI の主要プラットフォームである Github と完全に統合されています。
最も重要なことは、Travis CIは、複雑なユーザーインターフェイスではなく、ソースコード内のファイルを通してビルドプロセスを設定できることです。
Travis CI はシンプルなアーキテクチャでスタートしました。ウェブコンポーネントはプロジェクトとそのビルドプロセスを可視化し、Travis CIはプロジェクトに新しいコミットが投稿されるたびにビルドをトリガーするためにGithubからメッセージを受信することができます。
ハブと呼ばれる別のコンポーネントは、新しいコミットを処理し、それらを単一のビルドに変換し、ビルドタスクの実行と終了時に生成される結果データを処理する役割を担っています。
どちらのコンポーネントもPostgreSQLデータベースを扱います。
3つ目の部分は、ビルドタスク自体を制御するために使用されるスレッドのコレクションで、VMインスタンス上で一連のコマンドを実行するために使用できます。
基本的に、hubは他の部分よりも少し複雑に見えます。hubがビルドログを処理する際には、RabbitMQとメッセージをやり取りする必要があります。ログはビルドタスクを制御するスレッドからチャンクのストリームとして送られてきます。
ハブはデータベースのログとビルド結果情報を更新し、ハブはそれらをPusherにプッシュします。Pusherを使用すると、Travis CIはビルドの開始時または終了時にUIを更新することができます。
この体制は2012年まで維持され、1日あたり7,000ビルドが実行されました。Travis CI がオープンソースコミュニティでより広く使用されるようになり、PHP、Python、Perl、Java、Erlang を含む 11 の言語のサポートを開始したことは喜ばしいことでした。
Travis CIは、オープンソースプロジェクトに必須のサービスです。しかし、残念なことに、このシステムはモニタリングを念頭に置かずにゼロから作られました。
以前は、システムが正常に動作していないこと、ビルドタスクが例外に遭遇したこと、タスクメッセージが適切に処理されていないことを通知するのは、常にコミュニティからのユーザーでした。
それは恥ずかしいことです。最初の挑戦は、モニタリング、データメトリクス、ロギングをシステムに追加し、Travis CI をビジネスホビープロジェクトから主要な商用プラットフォームに変えることでした。Travis CI の本番リリースの準備。
システムが正常に動作していないとユーザーから言われることは、今でも私の最悪の悪夢です。また、問題が発生したらすぐにシステムに通知できるように、優れたデータ監視を構築するために努力しなければなりません。
データロギングや優れたロギングがなければ、この小さな分散システムで何が起こっているのかを把握することは不可能です。どう考えても、Travis CIはすでに分散システムです。
モニタリング・メトリクスとログを追加することは、徐々に学習するプロセスですが、最終的には、チャートであれログであれ、システムが何をしているかを理解することが可能になります。
これは大きな強化です。分散システムを運用する上で、可視性は非常に重要です。
システムを書くときは、それをどのように監視するかを考えてください。
優れたモニタリングは、単にテストに合格するだけでなく、本番環境でシステムをより良く稼働させるのに役立ちます。
重要なのは、監視を強化することで、システムをよりよく知ることができるだけでなく、これまで思いもつかなかった、あるいは見えていなかった問題を見つけることができるということです。システムの可視性が高まれば、説明責任も高まります。システム内のエラーに対する理解が深まったという事実と折り合いをつける必要があり、エラーの影響を最小限に抑えるために、より効果的に取り組むことが重要です。
