Travis CI 一开始仅仅是个想法，在当时甚至还有些理想化。在这个项目启动之前，开源社区还没有一个可用的持续集成系统。
随着作为开源协作平台的Github越来越被人认可，Github也非常需要可以持续对贡献代码进行测试的服务，来保证一个开源项目始终处于稳定健康的状态。
Travis CI开始于2011年初，而且很快得到了一些试用客户。到了2011年夏天，我们每天进行700次构建。所有这些构建都是在一台构建服务器上进行的。Travis CI跟Github完美集成，目前Github还是Travis CI的主要平台。
Travis CI在持续集成领域并没有惊天动地的大动作，但它的确重新定义了一些原有的概念，并增加了一些新的想法。其中一个就是你可以在你的测试运行过程中，接近实时的看这个项目的构建日志流。
最重要的一点，Travis CI允许你通过源码里的文件(.travis.yml)来对构建过程进行配置，而不是复杂的用户界面。
Travis CI一开始的架构很简单。通过Web组件可以让项目和它的构建过程可见，同时，只要一个新的commit提交到了项目，Travis CI就可以接收到来自Github的消息，从而触发构建。
另外一个叫做hub的组件，是负责处理新的提交，将他们转化成一次构建，并且处理构建任务运行和结束时产生的结果数据。
这两个组件都是跟PostgreSQL数据库打交道。
第三部分就是用来控制构建任务本身的线程集合，它们可以用来在虚拟机实例上执行一系列的命令。
本质上，hub会显得比其他部分稍微复杂一些。当hub处理构建日志时，它需要与RabbitMQ进行消息传递。日志会以chunks流的形式从控制构建任务的线程中得到。
Hub更新数据库中的日志和构建结果信息，并且hub推送他们到Pusher。通过Pusher，Travis CI可以在构建开始或结束的时候更新用户界面。
这样的架构一直维持到了2012年，当时我们每天进行7000个构建任务。我们欣喜的看到Travis CI在开源社区越来越广泛的使用，并且开始支持11种语言，包括PHP，Python，Perl，Java 和 Erlang。
随着越来越多的使用，Travis CI越来越像是一个开源项目的必备服务了。但是不幸的是，这个系统从一开始构建的时候就没有考虑过监控。
过去，总是来自社区的用户通知我们系统没有正常运行，构建任务遇到异常，或是任务信息没有被处理好。
那可真是令人尴尬。我们的第一个挑战就是给系统增加监控，数据指标和日志，让Travis CI从一个业务爱好的项目转变为一个重要的商业平台。我们准备发布Travis CI的正式生产版本。
被用户告知系统没有正常运行直到今天仍然是我最大的噩梦，我们不得不努力工作建设好数据监控，以使系统能够在出现问题的一开始就及时通知。
如果没有任何数据记录或者良好的日志，我们根本不可能去搞清我们这个小分布式系统到底发生了什么。无论是从哪个方面看，Travis CI都已经是一个分布式系统了。
加入监控指标和日志是一次循序渐进的学习过程，但是最终，它们让我们可以了解这个系统正在做什么，无论是通过图表还是日志。
这对我们而言是一个巨大的提升。可见性对于运行一个分布式系统是非常重要的。
当你写一个系统时，考虑好如何监控它。
做好监控会有助于你的系统更好的在生产环境运行，而不仅仅是通过测试。
关键是，更多的监控不仅仅是让你可以对系统更了解，你也会发现那些你以前未曾想到或见到的问题。系统更高的可见性带来更多的责任感。现在我们需要去面对这样的事实：我们对系统的错误有了更多的了解，所以我们必须更有效的工作来减少这些错误所带来的影响。
原文链接： Mathias Meyer
译文链接： http://blog.jobbole.com/52397/
