TravisCI一开始只是一个想法，甚至在当时被理想化了。在这个项目开始之前，开源社区并没有可用的持续集成系统。随着Github作为开源协作平台的认可度越来越高，Github也需要能够持续测试贡献代码的服务，以确保开源项目始终处于稳定健康的状态。TravisCI于2011年初启动，很快就获得了一些试用客户。到2011年夏天，我们每天进行700次构建。所有这些构建都是在一个构建服务器上完成的。TravisCI与Github完全集成，Github是目前TravisCI的主要平台。TravisCI在持续集成领域并没有做出什么惊天动地的举动，但它确实重新定义了一些原有的概念，并加入了一些新的想法。一是您可以在测试运行期间近乎实时地查看项目的构建日志流。最重要的是，TravisCI允许您通过源代码(.travis.yml)中的文件而不是复杂的用户界面来配置构建过程。TravisCI从一个简单的架构开始。可以通过Web组件使项目及其构建过程可见。同时，只要有新的commit被提交到项目中，TravisCI就可以收到来自Github的消息，从而触发构建。另一个名为hub的组件负责处理新的提交，将其转换为构建，并处理构建任务运行和结束时产生的结果数据。这两个组件都与PostgreSQL数据库一起工作。第三部分是用于控制构建任务本身的线程集，可用于在虚拟机实例上执行一系列命令。从本质上讲，集线器会比其他集线器显得稍微复杂一些。hub在处理构建日志的时候，需要和RabbitMQ进行通信。日志作为块流从控制构建任务的线程中获取。Hub更新数据库中的log和构建结果信息，Hub推送给Pusher。使用Pusher，TravisCI可以在构建开始或结束时更新用户界面。这个结构一直保持到2012年，当时我们每天做7000个构建任务。我们很高兴看到TravisCI在开源社区中的应用越来越广泛，开始支持PHP、Python、Perl、Java和Erlang等11种语言。随着越来越多的使用，TravisCI越来越像是开源项目必备的服务。但不幸的是，该系统是在没有考虑监控的情况下从头开始构建的。以前社区用户总是告诉我们系统运行不正常，构建任务遇到异常，或者任务信息没有处理好。那真是太尴尬了。我们的第一个挑战是向系统添加监控、指标和日志记录，将TravisCI从一个业余项目转变为一个严肃的业务平台。我们正准备发布TravisCI的正式生产版本。直到今天，被用户告知系统无法正常运行仍然是我最糟糕的噩梦，我们不得不努力构建数据监控，以便在出现问题时能够第一时间通知系统。没有任何数据记录或良好的记录，就不可能弄清楚我们的小分布式系统中发生了什么。不管怎么看，TravisCI已经是一个分布式系统了。添加监控指标和日志是一个渐进的学习过程，但最终，它们让我们了解系统在做什么，无论是通过图形还是日志。这对我们来说是一个巨大的进步。可见性对于运行分布式系统非常重要。当你写一个系统的时候，想想如何监控它。良好的监控将帮助您的系统在生产中更好地运行，而不仅仅是通过测试。关键是，更多的监控不仅可以让您更好地了解系统，还可以发现您以前没有想到或看到的问题。对系统的可见性越高，问责制就越强。现在我们需要面对这样一个事实，即我们对系统的错误了解得更多，因此我们必须更有效地工作以减少这些错误的影响。原文链接：http://www.paperplanes.de/2013/10/18/the-smallest-distributed-system.html翻译链接：http://blog.jobbole.com/52397/
