这是500lines项目中的一个案例，我认为是了解CI系统最好的途径，所以仔细阅读并实践一遍，并做出了一点改进。希望能够给需要的人提供帮助。

现代软件工程中常常通过 测试 来保证后续做出的修改是安全并且达到预期目的的，TDD就是一个典型的开发模式，通过先写出测试用例，然后再写代码，当我们做出一些修改时，如何知道我们有没有破坏已有的功能呢？只需要运行一遍测试用例即可。

然而，随着测试用例的增多，在本地运行测试用例变得越来越困难，或者说花费的时间越来越多，亟需一个专用的测试系统来完成自动化的测试工作，于是便有了 CI——持续集成系统。

CI 的作用是：当我们向代码库提交新的代码时，它自动获取最新提交，运行所有测试，并将测试结果生成一份报告，当然，这个系统必须能够有一定的容错性，当发生错误时可以自动恢复。

我们还希望 CI 能够及时响应，如果提交代码的速度比测试运行的速度还快的情况下，我们希望能够在合理的时间内得到服务。所以 CI 一般都具有分布式的架构来应对这种情况。

CI 系统的基本架构可以分成三个基本的模块：

• 观察监视模块
• 测试调度模块
• 运行测试模块

观察模块监视代码库，一旦发现有新的提交，就通知测试调度模块，后者寻找一个运行测试的模块进行测试工作。

我们可以将 观察者, 调度器, 测试器 放到同一台机器的同一个进程中，然而这种模式没有负载均衡处理，当提交变多时，系统很容易挂掉，而且没有容错处理。

我们的 CI 将这三个模块分布在不同的进程中运行，并且 测试器 可以有多个进程，这些进程可以通过 socket 通信，这种架构模式下，我们可以将这些进程放在不同的机器运行，然后通过网络交互通信。

这种分布式的架构使得我们的 CI 拥有了负载均衡和容错处理的潜能。事实上，现实生活中的 CI 都运行在分布式的系统架构上，当一台机器出现问题宕机时，任务会自动分发给旁边正常的机器。

我们DIY的 CI 系统主要分以下几个模块：

• repo_observer.py 代码库监视器
• dispatcher.py 测试分发
• test_runner.py 测试运行

详细解析可以参看我的博客