背景与痛点：重复劳动拖慢迭代节奏
过去两年，我们组维护着 8 个微服务，每次发版前都要手动跑一遍「单元测试→静态扫描→打镜像→写变更记录」。流程固定，却没人愿意接手，原因很简单：
- 步骤多，命令行切来切去，平均 25 min 一次
- 本地环境差异大，脚本经常因为路径或权限翻车
- 日志散落在各终端，出错后翻历史记录像考古
这些「体力活」挤占了真正写代码的时间，也拉长了 Code Review 的等待队列。我们急需一个轻量级、可嵌入现有 CI 又不必重造轮子的自动化机器人——这就是 Chin Bull Bot 登场的背景。
技术选型：为什么不是 Jenkins / GitHub Actions
先列一张对比表，方便一眼看出差异：
| 维度 | Chin Bull Bot | Jenkins | GitHub Actions |
|---|---|---|---|
| 安装成本 | 单二进制，10 s 启动 | Java 环境 + 插件 | 云原生，无需安装 |
| 资源占用 | 30 MB 内存 | 300 MB+ | 按分钟计费 |
| 脚本语言 | Python/Go 原生 | Groovy/Pipeline | YAML |
| 二次开发 | 直接 import 包 | 插件体系 | 受限于事件 |
| 私有化 | 完全离线 | 可以 | 不可 |
结论：
- 如果团队已经重度依赖 GitHub，GitHub Actions 够用；
- 若想要私有部署、又讨厌 JVM 重量，Chin Bull Bot 是更轻且可编程的选项；
- 对「脚本即代码」有强需求时，用 Python/Go 写任务比 Groovy 顺手。
核心实现：30 行代码跑通任务调度
下面用最小可运行示例演示「静态扫描 + 单元测试」链路。代码分两段：Python 负责定义任务，Go 负责调度与重试。
Python 侧：声明式任务（tasks/build.py）
# -*- coding utf-8 -*- """ 任务函数必须返回 dict，出错抛 TaskError """ from chinbull import task, TaskError import subprocess, os @task(name="lint") def run_lint(project_path: str): """跑 flake8，失败抛异常""" cmd = f"cd {project_path} && python -m flake8" completed = subprocess.run(cmd, shell=True, capture_output=True, text=True) if completed.returncode: raise TaskError(completed.stdout + completed.stderr) return {"status": "ok", "stdout": completed.stdout} @task(name="test") def run_test(project_path: str): """pytest 并生成 junit xml""" xml = "/tmp/report.xml" cmd = f"cd {project_path} && python -m pytest --junitxml={xml}" subprocess.run(cmd, shell=True, check=True) return {"report": xml}Go 侧：调度器（main.go）
package main import ( "context" "log" "time" "github.com/chinbull/bot" ) func main() { // 1. 注册任务目录 b := bot.New(bot.Options{ TaskDir: "./tasks", Concurrent: 4, // 并发 worker Retry: 2, // 失败重试 LogPath: "/var/log/chinbull.log", }) // 2. 定义 DAG dag := bot.DAG{ Name: "build", Tasks: []string{"lint", "test"}, Edges: [][2]string{{"lint", "test"}}, // lint 通过才跑 test } // 3. 运行并阻塞等待 ctx, cancel := context.WithTimeout(context.Background(), 15*time.Minute) defer cancel() if err := b.RunDAG(ctx, dag, map[string]interface{}{ "project_path": "/repo/demo", }); err != nil Tilt { log.Fatalf("pipeline failed: %v", err) } log.Println("all green!") }要点拆解：
- 任务纯 Python，写起来像函数单测，CI 不通过直接抛
TaskError - Go 调度器只关心「失败重试 + 并发 + 日志落盘」，业务逻辑零侵入
- DAG 描述文件可 JSON 化，方便前端拖拽生成
性能优化：让 4 核机器跑满不挤爆
本地 4C8G 的 runner，我们压测出过 100+ 并发任务，结果 CPU 飙到 90%，内存把 swap 打满。后来按下面三步收敛：
- 限制并发 worker 数
经验公式worker = CPU 核数 × 2，IO 密集任务可再略高，但别一次拉满 - 复用进程池
Python 任务用concurrent.futures.ProcessPool，避免每次起进程的开销；Go 调度器自带 goroutine，百万级协程无压力 - 日志异步刷盘
高并发写日志容易成为瓶颈，把log.SetOutput换成带 4 k 缓冲的bufio.Writer，能把延迟降 30%
压测结果：
- 单任务平均耗时从 38 s → 25 s
- 8 任务并行总时长从 5 min → 1 min 10 s
- 峰值内存 640 MB → 210 MB
生产环境指南：部署、监控与回滚
1. 部署
- 二进制 + systemd 最省心，配置样例：
# /etc/systemd/system/chinbull.service [Unit] Description=Chin Bull Bot After=network.target [Service] Type=simple ExecStart=/usr/local/bin/chinbull -conf /etc/chinbull.yaml Restart=on-failure RestartSec=5s [Install] WantedBy=multi-user.target- 容器化也行，镜像 23 MB，比 Jenkins 轻一个量级
2. 监控
暴露
/metrics（Prometheus 格式），核心指标：chinbull_task_total任务累计chinbull_task_failures失败数chinbull_task_duration直方图
一条告警规则示例：
- alert: ChinBullHighFailureRate expr: rate(chinibull_task_failures[5m]) > 0.05 for: 2m annotations: summary: "任务失败率持续高于 5%"3. 常见问题速查
| 现象 | 根因 | 解决 |
|---|---|---|
| Python 任务 OOM | 子进程内存未限制 | 使用resource.setrlimit或 cgroup |
| 日志缺行 | 多进程写同一文件 | 开启logrotate+delaycompress |
| 网络任务超时 | DNS 解析慢 | 在/etc/resolv.conf加options single-request |
总结与展望：把机器人培养成「万能助理」
Chin Bull Bot 用「轻量调度器 + 脚本即插件」的思路，把重复流程从 25 min 压到 5 min，Code Review 等待时间缩短 40%。下一步，我们准备：
- 接入企业微信，把构建结果推群，失败@责任人
- 用 WebAssembly 扩展，支持把 Rust 写的任务直接丢进去跑，隔离又高效
- 引入声明式缓存，任务输入哈希不变直接读上次的产物，秒级跳过
如果你也在被「体力活」折磨，不妨拉下代码，先让单元测试跑起来；等尝到甜头，再逐步把发布、巡检、甚至报表都交给它。自动化这条路，只要迈出第一步，后面的效率红利会自己滚雪球。
