Linux CI/CD 服务搭建实践：SVN、Review Board、Jenkins 与 Gerrit

warning · 历史材料已通用化 本文由早期服务器部署记录整理而来，已移除地址、账号、口令、密钥、域名、许可证和内部路径。原记录使用的 CentOS Linux 7 已于 2024 年 6 月 30 日停止维护，不应继续作为新部署的默认选择。

先确定部署边界

一套代码评审与持续集成环境通常包含：

版本控制：SVN 或 Git。
评审入口：Review Board（可连接 SVN/Git）或 Gerrit（以 Git 评审工作流为核心）。
自动化执行：Jenkins Controller 与一个或多个 Agent。
反向代理与 TLS：Nginx、Apache HTTP Server 或云负载均衡。
持久化存储：数据库、制品库、备份存储。
身份与密钥：Jenkins Credentials、系统密钥环或专用密钥管理服务。

生产环境应优先选择仍在安全支持期内的发行版或容器基础镜像，并把系统版本、服务版本、插件版本和恢复步骤记录在基础设施代码中。

安全基线

不在笔记、脚本和命令行中写入真实凭据。 使用凭据 ID、环境变量名或 <placeholder>。
服务账号最小权限。 构建账号只获得所需仓库、目录和发布目标的权限。
减少暴露面。 数据库和管理端口默认仅在内网开放；公网入口通过 TLS 反向代理，并同时检查主机防火墙和云安全组。
凭据可轮换。 不共享个人账号；撤销成员权限时不应影响其他流水线。
备份必须演练恢复。 至少覆盖配置、数据库、插件清单、凭据密文所依赖的主密钥和制品索引。

SVN 与 Review Board

SVN 服务

明确仓库根目录、认证方式、授权文件和备份策略。
若通过 HTTP(S) 暴露 SVN，TLS 应在反向代理或 Web 服务器终止。
自动化账号使用独立凭据，不复用开发者个人账号。
升级前验证客户端兼容性，并在副本上测试仓库恢复。

Review Board

Review Board 需要 Web 服务、数据库及仓库访问凭据。部署时应：

为站点配置独立数据库用户；
通过管理界面或密钥管理机制保存仓库凭据；
限制管理界面来源并启用 TLS；
将站点配置、数据库和上传文件纳入备份。

具体安装命令会随发行版和 Review Board 版本变化，应以项目当前安装文档为准。

Jenkins

Controller 与 Agent

Controller 负责调度、配置和状态管理，不承担高风险或高负载构建。
构建在隔离的 Agent 上执行；不同信任级别的项目不要共享高权限 Agent。
插件数量保持最小，升级前导出插件清单并在测试实例验证。

凭据

把 SVN/Git、制品库、签名和部署凭据存入 Jenkins Credentials，以凭据 ID 在流水线中引用。日志中避免输出环境变量、调试转储或包含秘密的命令参数。即便使用 withCredentials，也要防止不受信任的构建步骤读取同一进程或工作区中的秘密。

withCredentials([usernamePassword(
  credentialsId: 'scm-service-account',
  usernameVariable: 'SCM_USER',
  passwordVariable: 'SCM_PASSWORD'
)]) {
  sh 'run-build-with-secret-from-environment'
}

示例只表达调用结构；实际脚本仍应关闭命令回显，并避免把秘密写入参数、文件或制品。

Gerrit

Gerrit 与普通 Git 托管的关键差异是变更通常先进入评审引用，再由评审结果决定是否合入目标分支。部署时重点检查：

SSH/HTTP Git 访问与 Web 入口的端口边界；
反向代理是否正确传递主机名、协议和认证头；
邮件、LDAP/OIDC 等外部集成是否使用独立服务账号；
数据库、索引、插件、仓库目录和配置文件是否能一致恢复。

故障排查顺序

确认 DNS、路由、云安全组和主机防火墙。
确认服务是否监听预期地址与端口。
检查反向代理上游、TLS 证书链和转发头。
用服务账号在 Agent 上独立验证仓库访问。
检查磁盘、inode、文件权限、SELinux/AppArmor 和系统日志。
最后检查 Jenkins 任务、插件与流水线配置，避免把网络或权限问题误判为插件故障。