自托管Git平台怎么搭一台 2G 内存的小机器跑通代码托管与 CI/CD 自动部署【免费下载链接】onedevThe Unified and Autonomous Development Platform项目地址: https://gitcode.com/gh_mirrors/on/onedev凌晨一点老周在群里发来一张监控截图自建的 GitLab 实例又内存溢出了构建队列整整卡了四十分钟。这已经不是他头一回为代码托管 流水线这对组合买单——用云上的仓库私有代码放出去心里不踏实自建一套吧Git 服务、CI/CD、看板各装各的维护成本比开发任务还高。直到他换上 OneDev这个把自托管Git平台、CI/CD 流水线和项目管理看板整合进同一个进程的开源项目事情才真正变得简单。如果你也在仓库放哪、流水线怎么跑之间反复横跳这篇就为你写的。我们不聊概念直接拿一个小项目从安装一路走到自动部署。为什么自托管Git平台值得你重新考虑先别急着下单服务器我们把账算清楚。团队规模一大工具就开始分裂代码在云仓库构建在另一个 CI 服务任务管理又在第三个系统。每次代码改动要在几个界面之间来回跳转还经常出现代码合了但流水线没触发的尴尬。更现实的是数据主权——私有代码放在第三方平台出点合规问题没人替你兜底。自托管Git平台解决的就是这两件事一是把 Git 仓库、CI/CD、问题跟踪整合进同一套系统减少工具之间的摩擦二是数据完全落在自己手里备份、迁移、审计都有主动权。OneDev 在这条路上走得挺远——分支保护、代码搜索、内置 AI、包仓库全做进了同一个安装包不用你像拼乐高一样自己拼凑工具链。你可能会问自托管是不是都很吃资源OneDev 的官方参考配置是 1 核 2G 内存就能带起中小型项目这一点后面我们会实测验证。安装自托管Git平台的两条路线动手之前先说结论安装 OneDev 有两条路线要么用 Docker 三分钟跑起来要么从源码启动开发模式。路线一Docker 快装。机器上有 Docker 的话一条命令就能拉起服务docker run -it --rm -v /var/opt/onedev:/opt/onedev -p 6610:6610 -p 6611:6611 1dev/server6610 是 Web 端口6611 是 SSH 端口/var/opt/onedev是数据目录。浏览器打开http://localhost:6610按引导填好管理员账号一个能用的仓库服务就上线了。路线二源码跑开发模式。想改代码、想加插件或者想看看这个项目内部怎么组织就克隆仓库用开发模式启动git clone https://gitcode.com/gh_mirrors/on/onedev cd onedev ./dev.sh run仓库根目录的dev.sh支持run、build、test等命令开发模式下改完 Java 代码还能热加载很适合想做二次开发的朋友。如果你好奇它的开发约定development.md 写得很清楚上手前翻一遍能少走不少弯路。如何搭建CI/CD流水线三个作业跑通自动部署服务起来之后我们建一个 demo 项目推两行代码上去然后把持续集成配置起来。这一步是整个流程的核心也最能体现可视化编排流水线和传统 YAML 写流水线的区别。OneDev 的构建作业可以直接在网页上编排不需要先背语法。进入项目的构建页面你可以像搭积木一样添加作业比如一个 demo 项目拆成build frontend、build backend、build product三个作业再在右侧的 Dependencies Services 面板里声明它们之间的依赖关系和所需服务。配置持续集成时有几个关键点值得留意作业依赖声明build product依赖前两个作业只有上游成功它才启动天然形成构建→打包的递进关系。矩阵作业同一套逻辑跑多个参数组合比如不同 Node 版本不用复制粘贴作业。缓存管理npm 或 Maven 依赖命中缓存后重复构建能省下大把时间。配置完成后每次git push都会自动触发流水线这就是持续集成最朴素也最重要的闭环。OneDev 内置了 Node、Python、Java、Go 等常见框架的模板多数项目不用从零写脚本选个模板改改参数就行。执行器与自动部署从跑通到跑得动流水线定义好了谁来执行这一步是新手最容易懵的地方。OneDev 用执行器Executor抽象了运行环境默认自带的服务器 Docker 执行器开箱即用地跑容器化任务等构建量大起来可以加 Kubernetes 执行器横向扩容或者用 Agent 把任务分发到不同机器上。自动部署这步也不难。把打包产物推进 OneDev 内置的包仓库后续的容器镜像、NPM 包、Maven 构件就都有了统一出口CI/CD 产物和发布流程因此天然连通那么问题来了——流水线卡在编译这一步怎么办OneDev 的 Web 终端能让你直接钻进正在运行的作业里看环境、试命令甚至手动暂停脚本现场排查不用再靠加日志→重跑的笨办法反复试错。自托管平台安装与运维的常见坑功能讲完说点实在的。下面这几个坑是我折腾自托管Git平台时真实踩过的提前知道能省一天时间。坑一端口和反向代理没理清。6610 是 Web、6611 是 SSH如果走 Nginx 反代别忘了把 WebSocket 升级头配好否则代码对比、Web 终端这类实时功能会时好时坏。坑二执行器环境和开发环境不一致。我本地明明能编译多半是构建环境没固定下来。建议直接用 Docker 执行器把 JDK、Node 版本写进镜像杜绝换个机器就挂。坑三权限配得太粗或太细。OneDev 的权限模型支持按用户/组、按分支、甚至按特定文件路径来设保护规则。建议从主干分支必须通过 CI 才能合并起步别一上来就全开。规则的具体实现可以翻 server-core/src/main/java/io/onedev/server/security/灵活程度比想象中高。坑四高可用不等于备份。OneDev 支持把项目复制到多台服务器组成集群界面里能直接看到各副本的同步状态但如果只有单机先做好数据目录的定期备份别把多副本当成唯一保险。集群化部署的配置模板在 server-product/helm/走 Kubernetes 的朋友可以直接参考。坑五升级前先看兼容性说明。项目在 server-product/system/incompatibilities/incompatibilities.md 里维护了版本间的破坏性变更清单升级前扫一眼比踩完坑再回滚省事得多。什么场景适合它什么场景建议换别的说了这么多最后帮你做个判断。如果你的情况符合下面任意一条OneDev 值得认真试用私有代码需要完全掌握在自己手里又不想在 Git 服务之外再养一套独立的 CI 系统团队已经用看板管任务希望提交、构建、发布能自动联动任务状态机器资源有限想在低配服务器上跑起全套 DevOps 工具链想用内置 AI 做代码评审、排查构建失败又不想把代码喂给外部服务。反过来也有几种情况建议三思团队深度绑定某个云厂商的托管服务迁移成本远大于收益对流水线有极其特殊的定制需求而团队没有意愿维护开源代码现有工具链跑得很稳能不折腾就不折腾也是一种正确。从GitLab 卡死到一台 2G 内存的机器跑完整套流程老周现在把仓库、流水线和看板都搬到了 OneDev 上。工具不在多能把从git push到自动部署这条路走通、走得稳就值回票价了。如果你也在为同样的烦恼发愁不妨照着上面的步骤试一次两个小时后你大概也会发出和老周一样的感叹原来自托管Git平台可以这么省心。【免费下载链接】onedevThe Unified and Autonomous Development Platform项目地址: https://gitcode.com/gh_mirrors/on/onedev创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考