travis-ci

15 December 2014

前言

至今以来，我干过的半途而废的事情不在少数。这次这件事情，也是其中的一件：我最近关注js要比关于ruby来的更多一些，所以，我到底能不能成为一个优秀的跑堂的呢？

谈到持续构建，最初是在我的导师的《软件测试》课上了解到的，主要是关于Java的一些持续构建工具(Hudson)。仔细想想，代码托管和持续构建在软件开发过程中，确实是必不可少的工具。Travis-ci是在研究typeahead.js的过程中，再次看到，并勾起想要深入理解的想法。

Travis CI是一个持续集成和部署的系统，其存在两个版本的实例：公共实例http://travis-ci.org, 以及私有实例http://travis-ci.com

以下介绍，所有与Travis CI项目相关的子项目。

Travis CI项目的文档地址位于: http://docs.travis-ci.com

Travis CI是由组多不同的子项目组成的，其中，最主要的介绍如下:

travis-api 是负责提供API的Sinatra项目。其响应来自不同终端的请求，并运行travis-core提供的服务。这个项目中的逻辑非常的少。

注: 如果想要学习如何使用Sinatra编写API的话，这项目的代码或许是个不错的起点。

travis-build为每个任务创建脚本。其从.travis.yml文件中获取配置，然后，创建一个运行在由travis-worker 提供的构建环境的bash脚本。

travis-core包含了Travis CI中绝大多数的逻辑。这个库由多个不同的项目中共享，并存放着模型，服务以及其他项目所需要的东西。

travis-cookbooks 存放着Chef的cookbooks，用来准备构建系统的环境。

travis-hub从其他的app中搜集事件，并向其他的app通知事件。例如，其通知travis-tasks启动构建和结束构建，从而将通知发送出去。

travis-hub负责调度已创建的jobs，从而确保服务质量的约束。例如，每个用户的并发构建数。

travis-listener负责在push提交或pull请求时，从Github上接受通知。然后将这些请求推到RabbitMQ上，从而让其他的应用处理。

travis-logs 从travis-worker中接受日志更新，将其保存到数据库中，并推送给web client。当job结束时，travis-logs负责将笼子推送到Amazon S3，从而进行归档。

travis-support 保存了不同Travis CI应用的共享逻辑。与travis-core不同的是，其中存放的逻辑更加的通用，比如如何运行异步job，或如何处理异常。

travis-tasks 从travis-hub中接受通知，并将通知发送给对应的通知者(notification providers)。

travis-web是主要的web客户端，其使用Ember编写，与travis-api通信，从而获取信息，并通过Pusher从travis-hub，travis-logs中获取更新。

travis-worker 负责在干净的环境中运行构建脚本。其将log导向travis-logs，并将状态根性推送给 travis-hub。

不说别的，这里将项目分散处理的方式很值得学习。此外，有空研究一下如何利用Sinatra编写API的方式。

最近，因为涉及太多，反而有些迷茫了。果然，因该将精力更加集中在Rails和工作上。NodeJs虽好，精力不足，适得其反。集中精力研究Rails，先从其文档开始。

结果，所谓的深入理解，也就是知道其大概是个啥的效果。 Rails集成了travis。