ick：一个持续集成系统
ick 是一个持续集成（CI）系统。访问 http://ick.liw.fi/ 获取更多信息。
更加详细的内容如下：
首个公开版本发行
这个世界可能并不需要又一个持续集成系统（CI），但是我需要。我对我尝试过或者看过的持续集成系统感到不满意。更重要的是，有几样我感兴趣的东西比我所听说过的持续集成系统要强大得多。因此我开始编写我自己的 CI 系统。
我的新个人业余项目叫做 ick。它是一个 CI 系统，这意味着它可以运行自动化的步骤来构建、测试软件。它的主页是 http://ick.liw.fi/，下载页面有指向源代码、.deb 包和用来安装的 Ansible 脚本的链接。
我现已发布了首个公开版本，绰号 ALPHA-1，版本号 0.23。（LCTT 译注：截止至本译文发布，已经更新到 ALPHA-6）它现在是 alpha 品质，这意味着它并没拥有期望的全部特性，如果任何一个它已有的特性工作的话，那真是运气好。
诚邀贡献
ick 目前是我的个人项目。我希望能让它不仅限于此，同时我也诚邀更多贡献。访问治理页面查看章程，入门页面查看如何开始贡献的的小建议，联系页面查看如何联络。
架构
ick 拥有一个由几个通过 HTTPS 协议通信使用 RESTful API 和 JSON 处理结构化数据的部分组成的架构。访问架构页面了解细节。
宣告
持续集成（CI）是用于软件开发的强大工具。它不应枯燥、易溃或恼人。它构建起来应简单快速，除非正在测试、构建的代码中有问题，不然它应在后台安静地工作。
一个持续集成系统应该简单、易用、清楚、干净、可扩展、快速、综合、透明、可靠，并推动你的生产力。构建它不应花大力气、不应需要专门为 CI 而造的硬件、不应需要频繁留意以使其保持工作、开发者永远不必思考为什么某样东西不工作。
一个持续集成系统应该足够灵活以适应你的构建、测试需求。只要 CPU 架构和操作系统版本没问题，它应该支持各种操作者。
同时像所有软件一样，CI 应该彻彻底底的免费，你的 CI 应由你做主。
（目前的 ick 仅稍具雏形，但是它会尝试着有朝一日变得完美 —— 在最理想的情况下。）
未来的梦想
长远来看，我希望 ick 拥有像下面所描述的特性。落实全部特性可能需要一些时间。
- 各种事件都可以触发构建。时间是一个明显的事件，因为项目的源代码仓库改变了。更强大的是任何依赖的改变，不管依赖是来自于 ick 构建的另一个项目，或者是包（比如说来自 Debian）：ick 应当跟踪所有安装进一个项目构建环境中的包，如果任何一个包的版本改变，都应再次触发项目构建和测试。
- ick 应该支持构建于（或针对）任何合理的目标平台，包括任何 Linux 发行版，任何自由的操作系统，以及任何一息尚存的不自由的操作系统。
- ick 应该自己管理构建环境，并且能够执行与构建主机或网络隔离的构建。这部分工作：可以要求 ick 构建容器并在容器中运行构建。容器使用 systemd-nspawn 实现。 然而，这可以改进。（如果您认为 Docker 是唯一的出路，请为此提供支持。）
- ick 应当不需要安装任何专门的代理，就能支持各种它能够通过 ssh 或者串口或者其它这种中性的交流管道控制的 操作者 。ick 不应默认它可以有比如说一个完整的 Java Runtime，如此一来，操作者就可以是一个微控制器了。
- ick 应当能轻松掌控一大批项目。我觉得不管一个新的 Debian 源包何时上传，ick 都应该要能够跟得上在 Debian 中构建所有东西的进度。（明显这可行与否取决于是否有足够的资源确实用在构建上，但是 ick 自己不应有瓶颈。）
- 如果有需要的话 ick 应当有选择性地补给操作者。如果所有特定种类的操作者处于忙碌中，且 ick 被设置成允许使用更多资源的话，它就应该这么做。这看起来用虚拟机、容器、云提供商等做可能会简单一些。
- ick 应当灵活提醒感兴趣的团体，特别是关于其失败的方面。它应允许感兴趣的团体通过 IRC、Matrix、Mastodon、Twitter、email、SMS 甚至电话和语音合成来接受通知。例如“您好，感兴趣的团体。现在是四点钟您想被通知 hello 包什么时候为 RISC-V 构建好。”
请提供反馈
如果你尝试过 ick 或者甚至你仅仅是读到这，请在上面分享你的想法。在联系页面查看如何发送反馈。相比私下反馈我更偏爱公开反馈。但如果你偏爱私下反馈，那也行。
via: https://blog.liw.fi/posts/2018/01/22/ick_a_continuous_integration_system/
作者：Lars Wirzenius 译者：tomjlw 校对：wxy