自托管Git与CI/CD平台的终极上手实战从零到一用OneDev跑通你的第一个构建【免费下载链接】onedevThe Unified and Autonomous Development Platform项目地址: https://gitcode.com/gh_mirrors/on/onedev这篇文章讲的是 OneDev——一款把 Git 代码托管、CI/CD 流水线和看板项目管理整合进同一套系统的自托管开发平台。读完之后你会亲手从零部署它并在 30 分钟内看到第一个构建亮起绿灯。一个团队的「工具三明治」困境代码在 GitLab流水线在 Jenkins任务看板在 Jira每次点发布前我得同时开三个标签页对日期。这是朋友阿凯三个月前跟我吐槽的原话。他们的后端构建要从 GitLab 触发 Jenkins构建状态再手工回填到 Jira人一多流程就断。我当时的建议很直接为什么不试试把这三件事装进一个平台自托管、Git、CI/CD 三合一的 OneDev 就是为此设计的——它一个实例就能替代前面三个工具数据打通靠内部事件而不是脚本对账。先打消三个顾虑自托管到底值不值听到自托管新手第一反应通常是三个问题顾虑现实运维很麻烦官方镜像一条docker compose命令即可升级就换镜像重启吃资源吗官方称 1 核 2G 内存即可支撑中型团队日常使用数据被锁定存储标准 Git 仓库随时可以推送到任何其他 Git 平台再算一笔账把三个 SaaS 订阅换成一台自托管服务器成本曲线会明显变平。而 OneDev 的 CI/CD 构建基于文件.onedev-buildspec.yml描述本质上是一份可版本化的构建配置代码换平台也不至于推翻重来。30分钟实战从启动到跑通第一个构建好假设你已经决定动手我们按下面的节奏走一遍每个节点都有可预期的结果。第一步拉取项目源码。先拿到 OneDev 的源码仓库git clone https://gitcode.com/gh_mirrors/on/onedev。目录下有server-product/docker/docker-compose.yaml这就是官方编排文件——它同时拉起 OneDev 服务端和一个 PostgreSQL 数据库。第二步启动服务。进入server-product/docker目录执行docker compose up -d然后等几十秒浏览器访问http://localhost:66106611 是 SSH 端口。看到初始化向导说明服务已就绪。这里的预期结果一个引导页。第三步完成初始化。按向导设置管理员账号、公司名等基础信息。OneDev 默认不要求额外配置回车到底即可。预期结果进入带项目列表的首页。第四步创建一个项目并推送代码。在界面上新建项目后本地执行git remote add origin并 push。如果 push 被拒绝多半是分支保护规则默认开启新建功能分支再推即可。预期结果代码出现在仓库文件页。第五步配置流水线。这是重头戏。打开项目里的CI/CD页你会看到一个图形化编辑器左侧是 Jobs 列表右侧是依赖与服务配置。无需手写 YAML点选即可添加作业、矩阵参数和作业依赖改动会自动写入仓库根目录的.onedev-buildspec.yml。预期结果仓库多出一个版本化的构建定义文件。流水线编辑器的关键操作界面左列是作业右侧配置依赖和服务全程免手写 YAML。第六步等第一个构建变绿。推送代码后流水线自动触发。点进构建页你可以实时看到日志滚动卡住时直接打开内置 Web 终端进容器里排查——这一步把传统看日志猜环境的循环缩短了一半以上。预期结果构建状态从 Running 变为绿色 Success。结果反馈的关键窗口日志与终端并存定位失败原因不必再靠猜。进阶技巧让平台按你的规矩办事跑通只是开始三个实操主题能决定你这套系统能走多远。配置管理把它当代码管。既然构建定义是.onedev-buildspec.yml那就让所有修改都走改文件 → 提 Pull Request → 评审 → 合并的流程构建配置自然有了审计记录。配合 readme.md 里强调的代码即配置思路全团队的流水线口径会高度统一。权限与安全先想清谁能碰哪条分支。代码保护规则可以做到谁动了哪个文件、触发什么验证例如指定目录的改动必须经过评审才能合入主分支。相关实现集中在 server-core/src/main/java/io/onedev/server/security/想深挖权限模型可以从这里入手。扩展生态别什么都自己造。认证、通知、报告、包管理都有现成插件官方插件源码在 server-plugin/。比如团队要 Docker 镜像仓库直接在插件里启用即可不必再部署一个 Harbor。界面概览看板把问题从 Open 流转到 Released与构建、发布状态联动。新手最容易踩的 4 个坑坑一push 被拒一脸懵。现象首次推送报remote rejected。原因主分支默认开了保护规则。解决推送前新建功能分支或按提示在界面关闭对应规则。坑二容器内执行不了 docker 命令。现象流水线里跑docker build失败。原因容器没挂载 Docker socket。解决参照docker-compose.yaml把/var/run/docker.sock挂进 OneDev 容器。坑三改完构建配置不生效。现象保存配置后构建行为没变化。原因改动落在其他分支触发的分支读不到。解决确认配置提交在触发分支上或手动重新执行构建。坑四认为一个实例只能跑一个团队。现象所有人挤在同一个项目里权限混乱。原因没用好项目树与父子项目。解决用 server-product/helm/ 里的方案按团队拆分命名空间公共设置在父项目定义、子项目继承。回到故事把工具链做减法三个月后阿凯告诉我他把三个标签页换成了一个代码、构建、任务在同一套界面里互相引用——提交记录能直接跳转到修复它的构建看板上的卡片又能反查由哪次发布解决。工具链变短的收益不只是少开两个标签页而是上下文切换这个隐性成本从流程里消失了。现在轮到你克隆https://gitcode.com/gh_mirrors/on/onedev跑起docker compose然后想想——你的下一个构建值得在多少套系统之间来回切换去亲手把第一个流水线点亮吧。【免费下载链接】onedevThe Unified and Autonomous Development Platform项目地址: https://gitcode.com/gh_mirrors/on/onedev创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 自托管Git与CI/CD平台的终极上手实战：从零到一用OneDev跑通你的第一个构建
自托管Git与CI/CD平台的终极上手实战从零到一用OneDev跑通你的第一个构建【免费下载链接】onedevThe Unified and Autonomous Development Platform项目地址: https://gitcode.com/gh_mirrors/on/onedev这篇文章讲的是 OneDev——一款把 Git 代码托管、CI/CD 流水线和看板项目管理整合进同一套系统的自托管开发平台。读完之后你会亲手从零部署它并在 30 分钟内看到第一个构建亮起绿灯。一个团队的「工具三明治」困境代码在 GitLab流水线在 Jenkins任务看板在 Jira每次点发布前我得同时开三个标签页对日期。这是朋友阿凯三个月前跟我吐槽的原话。他们的后端构建要从 GitLab 触发 Jenkins构建状态再手工回填到 Jira人一多流程就断。我当时的建议很直接为什么不试试把这三件事装进一个平台自托管、Git、CI/CD 三合一的 OneDev 就是为此设计的——它一个实例就能替代前面三个工具数据打通靠内部事件而不是脚本对账。先打消三个顾虑自托管到底值不值听到自托管新手第一反应通常是三个问题顾虑现实运维很麻烦官方镜像一条docker compose命令即可升级就换镜像重启吃资源吗官方称 1 核 2G 内存即可支撑中型团队日常使用数据被锁定存储标准 Git 仓库随时可以推送到任何其他 Git 平台再算一笔账把三个 SaaS 订阅换成一台自托管服务器成本曲线会明显变平。而 OneDev 的 CI/CD 构建基于文件.onedev-buildspec.yml描述本质上是一份可版本化的构建配置代码换平台也不至于推翻重来。30分钟实战从启动到跑通第一个构建好假设你已经决定动手我们按下面的节奏走一遍每个节点都有可预期的结果。第一步拉取项目源码。先拿到 OneDev 的源码仓库git clone https://gitcode.com/gh_mirrors/on/onedev。目录下有server-product/docker/docker-compose.yaml这就是官方编排文件——它同时拉起 OneDev 服务端和一个 PostgreSQL 数据库。第二步启动服务。进入server-product/docker目录执行docker compose up -d然后等几十秒浏览器访问http://localhost:66106611 是 SSH 端口。看到初始化向导说明服务已就绪。这里的预期结果一个引导页。第三步完成初始化。按向导设置管理员账号、公司名等基础信息。OneDev 默认不要求额外配置回车到底即可。预期结果进入带项目列表的首页。第四步创建一个项目并推送代码。在界面上新建项目后本地执行git remote add origin并 push。如果 push 被拒绝多半是分支保护规则默认开启新建功能分支再推即可。预期结果代码出现在仓库文件页。第五步配置流水线。这是重头戏。打开项目里的CI/CD页你会看到一个图形化编辑器左侧是 Jobs 列表右侧是依赖与服务配置。无需手写 YAML点选即可添加作业、矩阵参数和作业依赖改动会自动写入仓库根目录的.onedev-buildspec.yml。预期结果仓库多出一个版本化的构建定义文件。流水线编辑器的关键操作界面左列是作业右侧配置依赖和服务全程免手写 YAML。第六步等第一个构建变绿。推送代码后流水线自动触发。点进构建页你可以实时看到日志滚动卡住时直接打开内置 Web 终端进容器里排查——这一步把传统看日志猜环境的循环缩短了一半以上。预期结果构建状态从 Running 变为绿色 Success。结果反馈的关键窗口日志与终端并存定位失败原因不必再靠猜。进阶技巧让平台按你的规矩办事跑通只是开始三个实操主题能决定你这套系统能走多远。配置管理把它当代码管。既然构建定义是.onedev-buildspec.yml那就让所有修改都走改文件 → 提 Pull Request → 评审 → 合并的流程构建配置自然有了审计记录。配合 readme.md 里强调的代码即配置思路全团队的流水线口径会高度统一。权限与安全先想清谁能碰哪条分支。代码保护规则可以做到谁动了哪个文件、触发什么验证例如指定目录的改动必须经过评审才能合入主分支。相关实现集中在 server-core/src/main/java/io/onedev/server/security/想深挖权限模型可以从这里入手。扩展生态别什么都自己造。认证、通知、报告、包管理都有现成插件官方插件源码在 server-plugin/。比如团队要 Docker 镜像仓库直接在插件里启用即可不必再部署一个 Harbor。界面概览看板把问题从 Open 流转到 Released与构建、发布状态联动。新手最容易踩的 4 个坑坑一push 被拒一脸懵。现象首次推送报remote rejected。原因主分支默认开了保护规则。解决推送前新建功能分支或按提示在界面关闭对应规则。坑二容器内执行不了 docker 命令。现象流水线里跑docker build失败。原因容器没挂载 Docker socket。解决参照docker-compose.yaml把/var/run/docker.sock挂进 OneDev 容器。坑三改完构建配置不生效。现象保存配置后构建行为没变化。原因改动落在其他分支触发的分支读不到。解决确认配置提交在触发分支上或手动重新执行构建。坑四认为一个实例只能跑一个团队。现象所有人挤在同一个项目里权限混乱。原因没用好项目树与父子项目。解决用 server-product/helm/ 里的方案按团队拆分命名空间公共设置在父项目定义、子项目继承。回到故事把工具链做减法三个月后阿凯告诉我他把三个标签页换成了一个代码、构建、任务在同一套界面里互相引用——提交记录能直接跳转到修复它的构建看板上的卡片又能反查由哪次发布解决。工具链变短的收益不只是少开两个标签页而是上下文切换这个隐性成本从流程里消失了。现在轮到你克隆https://gitcode.com/gh_mirrors/on/onedev跑起docker compose然后想想——你的下一个构建值得在多少套系统之间来回切换去亲手把第一个流水线点亮吧。【免费下载链接】onedevThe Unified and Autonomous Development Platform项目地址: https://gitcode.com/gh_mirrors/on/onedev创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考