一、为什么又要造轮子
市面上已有无数“十分钟搞定持续集成”的教程，可真正落到私有化环境，仍有一连串隐形门槛：版本库需完全内网、构建机要接专有硬件、流水线脚本必须审计追溯、密钥不能出机房。于是，“搭一套自己的代码托管 + 自动化部署”成了很多团队绕不过去的任务。
市面上已有无数“十分钟搞定持续集成”的教程，可真正落到私有化环境，仍有一连串隐形门槛：版本库需完全内网、构建机要接专有硬件、流水线脚本必须审计追溯、密钥不能出机房。于是，“搭一套自己的代码托管 + 自动化部署”成了很多团队绕不过去的任务。
二、准备阶段：先画一张“端到端”的蓝图
-
角色划分
-
源码仓：保存配方、配置、构建脚本
-
构建引擎：拉代码、跑任务、出制品
-
分发器：把制品推送到目标环境，完成热更新或滚动重启
-
-
网络拓扑
三套隔离层：办公网、构建网、生产网。办公网只暴露网页端口，构建网可以访问生产网的 agent，但生产网永远回连不到办公网，降低横向移动风险。 -
资源预估
每增加一个并行构建，会吃掉 2 核 4 GiB 的算力；仓库层每日新增 50 个分支，磁盘年增长约 120 GiB。把这两个数字乘三做预算，未来两年不用半夜加硬盘。 -
时间预算
第一次完整跑通需要 4～6 小时，其中 70% 花在权限打通和第一次流水线调试；务必预留整块时间，否则“做到一半去开会”会让环境处于半残状态，回滚比继续更费时。
三、选型思考：为什么是 Jenkins 与 Gitea
-
轻量：单二进制即可启动，内存基线 200 MiB，老机器也能扛。
-
插件丰富：成百上千任务模板，无需重复造钩子。
-
可审计：所有页面操作、后台调用都有日志回流接口，轻松对接内部合规系统。
-
社区活跃：问题通常能在一天内找到现成方案，减少深夜自救。
-
离线友好：安装包与插件可一次性下载，之后完全断网也能维护升级。
四、安装阶段：让“能跑”与“好养”并重
-
系统基线
选用长期支持版系统，开启动态防火墙、关闭透明大页、加大文件句柄。看似与主题无关，却能在高并发构建时减少 30% 的“Too many open files”告警。 -
用户与目录
创建专用低权用户，家目录下设数据、日志、缓存、备份四件套；把日志挂载到独立分区，避免 I/O 拥堵时把系统盘打满。 -
反向代理
即使内网也加一层代理，统一域名、证书、超时设置，未来迁移机房只需改解析，不必挨个改钩子地址。 -
备份钩子
在每日低峰期，用硬链接方式做增量快照，既节省空间，又能 3 分钟回滚到昨日状态。备份脚本放仓库里，走 Code Review，防止“备份代码本身有 bug”的魔幻剧情。
五、联通阶段：让仓库与构建机“对上暗号”
-
钥匙链设计
把密钥分为三类：拉代码只读、推制品写、紧急热修复；每类再按环境细分，确保“测试库的凭证永远刷不到生产”。 -
Webhook 通路
在源码仓侧配置“推送即触发”，在网络层只放行代理到构建机的单向路由；即便构建机被攻破，也无法回连源码仓篡改数据。 -
第一次握手
先手动触发一次空构建，确认凭证、目录、端口、DNS 全部对齐；再把空构建替换成真实脚本，这样出错时分层定位更快。 -
链路加密
内网不是“可信”的代名词，务必开启 TLS，把证书有效期写到日历，提前一个月续签，避免“凌晨两点证书过期”的惊喜。
六、权限阶段：把“谁能点什么”写进制度
-
最小角色
只设四档：访客、开发者、维护者、管理员；上线初期就定好晋升流程，防止“人人都是管理员”的野蛮生长。 -
分支保护
主干分支默认拒绝强制推送，合并请求必须经两人 Code Review 且流水线通过；把“合并按钮”与“发布按钮”分离，减少手滑。 -
审计日志
所有登录、授权变更、配置修改自动发送到内部审计平台，保留 180 天；一旦出现“删库”操作，能在 5 分钟内追溯到人。 -
紧急通道
预留“熔断钥匙”，可在灾备时绕过常规审批，但使用记录会立刻抄送全员，防止滥用。
七、流水线阶段：让“构建”成为源码的一部分
-
描述文件
把步骤写成声明式，放在仓库根目录，跟随业务代码一起版本化；这样回滚业务时也自动回滚对应的构建逻辑，避免“新版本用旧脚本”导致诡异错误。 -
环境模板
测试、预发、生产三份配置，通过变量注入区分；构建脚本里只写一次逻辑，其余用占位符替换，降低复制粘贴带来的漂移。 -
并行与串行
单元测试并行跑，集成测试串行跑，性能压测只在夜间空闲时触发；通过标签动态分配节点，让高并发任务不堵死低并发通道。 -
制品管理
每次构建生成唯一编号，写入元数据：源码 Commit、构建机 hostname、构建耗时、测试报告链接；让“这个包从哪来”一目了然，方便事后复盘。
八、分发阶段：把“制品”变成“服务”
-
无状态分发
把制品推到目标机后，先校验哈希，再触发本地重启脚本；重启失败自动回滚到旧版本，确保“最差情况”也只是维持现状。 -
滚动策略
按 30%→50%→100% 的梯度放行，每步观察错误率与延迟；如果指标异常，立即中断后续批次。 -
配置热刷新
环境变量改动能通过钩子实时下发，无需重新打包；把“改配置”与“发代码”解耦，减少凌晨紧急上线。 -
遥测反馈
分发结束后，把版本号、回滚命令、日志查询链接自动回写到构建记录，让值班同学能在同一页面完成“看版本—查日志—回滚”的闭环。
九、监控与告警：让“健康”成为第一优先级
-
黄金指标
选四样：任务排队时长、成功率、构建耗时、资源利用率；少于四样看不出趋势，多于四样容易淹没核心异常。 -
基线法
取过去两周的 95 分位值作为基线，上涨 30% 就预警，上涨 50% 电话告警；既避免静态阈值太死，也避免动态算法太飘。 -
告警通道
工作日走即时消息，深夜走短信；同一故障 10 分钟内只响一次，防止“轰炸式”提神。 -
可视化
把构建排队人数、代理空闲率、最近失败原因打在同一个大屏，放在办公区入口；让所有人路过时都能“一眼看出今天能不能发版”。
十、升级与迁移：让“新版本”不再可怕
-
蓝绿代理
先搭一套新环境，把流量切 1% 做灰度；旧环境保持只读，随时可回切。 -
数据迁移
仓库数据用镜像同步，构建历史用导出导入，用户数据库用批量脚本；三套数据分开迁，减少“一损俱损”。 -
回归验证
升级后跑 50 次历史构建，对比结果与旧环境是否 100% 一致；只要有一次差异，就暂停全量切流。 -
旧环境退役
保留旧机器 30 天但关闭写入权限，让遗忘的脚本暴露报错，再彻底下线，避免“幽灵任务”。
十一、安全加固：把“万一”变成“十万分之一”
-
最小端口
只开放代理端口与构建代理回连端口，关闭调试端口；管理后台放在内网 DNS，仅 VPN 可访问。 -
依赖扫描
每次构建自动触发漏洞扫描，把高危组件阻断在打包之前；把扫描报告作为合并请求的门禁，减少“带病上线”。 -
密钥轮换
数据库密码、签名私钥每 90 天强制更新；把轮换脚本也纳入版本管理，防止“换密码靠手敲”的玄学操作。 -
灾备演练
每季度做一次“单日故障”假设：随机拔掉一台构建机、随机清空一次仓库镜像，验证剩余节点能否在 30 分钟内自愈；把演练过程录屏，供新人学习。
十二、性能调优：把“还能用”变成“用得爽”
-
代理缓存
把静态资源、插件包、镜像文件缓存在代理层，减少重复下载；命中率高一次，构建耗时就能缩短 20%。 -
增量拉取
克隆代码时默认开启浅克隆，标签与历史按需补充；对于超大仓库，能把 10 分钟缩短到 30 秒。 -
并行测试
把单元测试按耗时排序，最慢的先跑，再并发跑中速、快速，能在同样核数下提前暴露失败点。 -
资源池化
构建代理按标签分组，让高 I/O 任务绑定 SSD 节点，高 CPU 任务绑定裸金属；避免“一把梭”导致排队拥堵。
十三、文档与培训：让知识留在公司，而不是留在某个人的硬盘
-
运营手册
把安装、升级、回滚、排障写成故事线，每一步都附带“预期输出”与“错误样例”；新人按图索骥，就能在 2 小时内独立发版。 -
视频回放
每次大版本升级后，录一段 10 分钟“点点点”操作，配上语音解说，放到内部学习平台；让“看过视频”成为获取构建权限的门槛。 -
故障库
把历史告警按“现象—根因—解决—预防”四段记录，可搜索可评论；下次出现相似日志，直接弹出过往案例，减少重复踩坑。 -
激励机制
每提交一篇优质排障笔记，奖励“构建加速券”——可把自己的任务优先级提升一次，让知识分享与个人效率挂钩，形成正向循环。
十四、常见翻车瞬间与自救清单
-
代理配置忘了 reload，导致新端口一直 502；
解决：把 reload 命令写进流水线第一步，每次部署自动执行。 -
备份脚本误删当天日志，审计来查时无据可循；
解决：备份前先校验哈希，再把备份文件设为只读，防止人为篡改。 -
升级插件后界面白屏，回退却发现旧版本不兼容新数据；
解决：插件升级前先导出配置快照，采用“插件与数据”双轨回滚。 -
构建机时间不同步，导致证书验证失败；
解决：所有节点统一接入内网时钟源，把时差大于 5 秒设为告警，杜绝“时空错乱”。
