云原生 DevOps 工具链从入门到实战第一期——DevOps概述与GitLab部署——从理念到工具落地更多云原生DevOps技能学习请戳这里云原生 DevOps 工具链从入门到实战我的主页AOwhisky这里有更多运维系统性知识整理和其他有趣内容欢迎与我一起探讨学习~ 引言从“写好代码”到“持续交付”在 Python 系列中我们学会了用代码解决问题——用 psutil 监控服务器、用 paramiko 批量执行命令、用 IPy 规划网络地址。你已经具备了“用 Python 做自动化”的能力。但当你把代码提交到公司仓库、和团队一起开发时新的问题出现了代码怎么和大家合并冲突了怎么办每次改完代码都要手动打包、部署、测试吗怎么保证代码质量怎么知道有没有引入 bug产品需要快速迭代但每次发布都像“拆弹”一样紧张……这些问题的答案指向一个更大的领域——DevOps开发运维一体化。 白话理解如果说 Python 系列是教你“造工具”那么 DevOps 系列就是教你“建工厂”——从原材料代码到成品线上服务的完整流水线。本期作为 DevOps 系列的开篇我们将一起完成两件事理解 DevOps 的核心理念以及搭建团队协作的基石——GitLab 代码仓库。— Compiled and Authored by Whisky — July 23 rd, 2026 本期目录软件开发生命周期SDLC瀑布模型 vs 敏捷开发持续集成 / 持续交付CI/CDGitLab 部署GitLab 基础操作——团队协作的第一步Git 基础与源码上传总结与知识点一览表正文一、软件开发生命周期SDLC1.1 什么是 SDLC软件开发生命周期Software Development Life CycleSDLC是软件从“想法”到“上线”再到“退役”的完整过程。它不是一个单一的活动而是由多个阶段组成的结构化流程。一个标准的 SDLC 包含以下五个阶段需求分析 → 设计 → 实现 → 测试 → 进化维护各阶段详解阶段核心目标主要交付物参与角色需求分析明确“做什么”收集和分析项目需求需求文档、可行性分析报告产品经理、需求分析师、客户设计确定“怎么做”制定系统架构和技术方案架构设计文档、数据库设计、接口文档系统架构师、技术负责人实现将设计转化为可运行的代码源代码、配置文件开发工程师测试验证代码的正确性和质量测试报告、Bug 列表测试工程师、QA进化持续维护、修复 Bug、增加新功能版本更新、运维报告运维工程师、开发工程师 白话理解SDLC 就像建房子的流程——先看地皮需求分析再画图纸设计然后施工队进场盖楼实现盖好后验收测试最后入住后的维修和装修进化。少了任何一步房子都可能出问题。1.2 为什么需要 SDLC标准化每个阶段有明确的输入和输出减少沟通成本质量控制测试阶段独立于开发阶段保证交付质量风险管理通过阶段性的评审尽早发现问题可追溯性每个阶段的文档记录了决策过程便于后期回溯二、瀑布模型 vs 敏捷开发2.1 瀑布模型Waterfall Model瀑布模型是最经典、最传统的软件开发模型得名于其“自上而下、单向流动”的结构——就像瀑布的水流一样只能从高处往低处流不能倒流。瀑布模型的六个阶段需求分析 → 系统设计 → 实现 → 集成测试 → 部署 → 维护 每个阶段必须完全完成后才能进入下一阶段优势优势说明简单易懂线性流程每个阶段的划分清晰明确阶段性检查每个阶段结束时有明确的里程碑和交付物文档完整每个阶段产生大量文档便于知识传承劣势劣势说明不适应性用户需求的变化难以在后期被接纳因为改动成本极高延迟反馈用户只有等到项目末期才能看到可运行的产品风险高文档过重大量的文档编写增加了工作量和维护成本缺乏灵活性线性结构导致开发周期长难以应对市场变化 白话理解瀑布模型就像“瀑布”——水从上往下流不能倒流。你用一年时间建了一栋大楼结果发现客户想要的是别墅而不是办公楼这时候已经没法改了。2.2 敏捷开发Agile Development敏捷开发是针对瀑布模型缺陷而提出的一套开发理念其核心是“迭代开发”和“增量开发”。何为迭代开发Iterative Development传统方式采用一个大周期如一年进行开发整个过程就是一次“大开发”迭代开发则将开发过程拆分成多个小周期如两周每次小开发都包含完整的开发流程需求、设计、编码、测试反复迭代。 比喻SpaceX 不是一开始就造 Falcon Heavy 重型火箭而是先造最简陋的 Falcon 1前三次发射都爆炸了第四次才成功。如果 SpaceX 不采用迭代开发它可能到现在还无法上天。每枚火箭都比上一枚更好这就是迭代。何为增量开发Incremental Development每次迭代交付一个用户可以感知的完整功能而不是交付“功能的碎片”。 比喻房产公司开发一个 10 栋楼的小区。增量开发是第一期交付 1 号楼完整功能第二期交付 2 号楼完整功能……而不是先建好所有楼的地基再建所有楼的骨架。敏捷开发的核心价值《敏捷宣言》价值观说明个体和互动高于 流程和工具人是第一位的沟通比工具更重要可工作的软件高于 详尽的文档能运行的代码比完美的文档更有价值客户合作高于 合同谈判与客户持续沟通而非只在签约时确定需求响应变化高于 遵循计划拥抱变化而非僵化地执行计划敏捷开发的 12 条原则精简版尽早、持续地交付有价值的软件欢迎需求变化即使在开发后期频繁交付数周到数月业务人员与开发者每日协同工作给团队足够的支持并相信他们能完成任务面对面的沟通最有效率可工作的软件是衡量进度的主要标准保持可持续的开发节奏持续关注技术卓越和良好设计简单性至关重要自组织团队产生最好的架构、需求和设计团队定期反思如何变得更有效瀑布模型 vs 敏捷开发对比对比维度瀑布模型敏捷开发开发方式线性顺序开发迭代式、增量式开发需求变化难以适应需求变化后期改动成本极高欢迎变化在每个迭代中可调整需求交付频率项目末期一次性交付每个迭代结束时交付可用的功能用户参与主要在需求和验收阶段参与全程持续参与客户代表在团队中文档要求大量文档每个阶段有完整的文档产出适度文档以可工作的软件为核心风险控制风险暴露在后期每个迭代都能发现和应对风险适用场景需求明确、变更少、规模适中的项目需求不明确、变化快、需要快速上市的产品 白话理解瀑布模型像“建大桥”——图纸必须一次画好开工后不能改敏捷开发像“做互联网产品”——每两周发一个新版本根据用户反馈不断调整越做越好。2.3 迭代开发 vs 增量开发补充澄清这两个概念是敏捷的核心但经常被混淆概念关注点示例迭代开发关注“时间维度”——开发过程分成多个小周期每次迭代 2 周不是一次大开发增量开发关注“功能维度”——每次交付一个完整功能第一期交付登录功能第二期交付支付功能两者通常结合使用用迭代的节奏做增量的开发。三、持续集成 / 持续交付CI/CD3.1 什么是 CI/CDCI/CD 是 DevOps 的核心实践它将敏捷开发的理念落实到工具和流程层面。缩写全称核心含义CIContinuous Integration持续集成频繁地将代码合并到主干并自动构建和测试CDContinuous Delivery持续交付每次代码变更都能自动部署到类生产环境CDContinuous Deployment持续部署通过自动化测试的变更自动部署到生产环境 白话理解CI 是“每天多次合并代码并自动检查”CD 是“每次合并后都能自动打包好随时可以上线”持续部署是“自动上线”。3.2 从代码提交到生产的完整流程1. 提交Commit ↓ 2. 测试第一轮自动化测试 ↓ 3. 构建Build编译 打包 ↓ 4. 测试第二轮集成测试/质量扫描 ↓ 5. 部署Deploy发布到服务器 ↓ 6. 回滚Rollback出错时快速恢复各阶段详解阶段说明自动化方式提交开发者向代码仓库提交代码触发钩子Git Hook测试第一轮自动化单元测试确保基础功能正常测试框架JUnit/TestNG构建将源码编译、打包成可执行文件Maven/Gradle测试第二轮集成测试、代码质量分析如 SonarQube质量分析工具部署将构建产物上传到生产服务器并运行脚本 编排工具Docker/K8s回滚出现问题时快速恢复到上一个稳定版本版本控制 自动化脚本3.3 持续集成的核心价值价值说明快速反馈代码提交后几分钟内就能知道是否通过测试降低风险问题越早发现修复成本越低提升质量每次提交都经过自动化测试质量有保障减少重复劳动构建、测试、部署全部自动化解放人力增强信心每次发布都经过完整流程验证不再“心惊胆战”3.4 核心工具链在 DevOps 工具链中本期涉及的基础工具及其定位如下工具定位本期涉及内容GitLab代码托管 CI/CD 一体化平台✅ 本期部署与配置JenkinsCI/CD 自动化服务器后续章节MavenJava 项目构建工具后续章节Docker容器化技术后续章节Kubernetes容器编排平台后续章节四、GitLab 部署4.1 GitLab 是什么GitLab 是一个基于 Git 的代码托管平台可以看作是“自己搭建的 GitHub”。它开源、免费社区版且支持 CI/CD 流水线、代码审查、问题跟踪等一体化功能。 白话理解GitLab 就是“公司内部的 GitHub”——代码不上传别人服务器全部掌握在自己手中。适合团队内部协作不用担心代码泄露。4.2 前置环境准备在安装 GitLab 之前需要先准备好服务器的操作系统环境。配置主机名与解析# 设置主机名根据实际修改hostnamectl set-hostname gitlab# 添加主机名解析echo127.0.0.1$(hostname)/etc/hosts安装依赖包GitLab 依赖policycoreutilsSELinux 管理、openssh-serverSSH 服务和postfix邮件通知。yum-yinstallpolicycoreutils openssh-server openssh-clients postfix启动 SSH 和 Postfix 服务systemctlenablesshd--nowsystemctlenablepostfix--now开放防火墙端口GitLab 需要开放 SSH 和 HTTP 服务端口。firewall-cmd --add-servicessh--permanentfirewall-cmd --add-servicehttp--permanentfirewall-cmd--reload4.3 下载与安装 GitLab# 下载 GitLab 安装包以 12.4.2 版本为例wgethttps://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el6/gitlab-ce-12.4.2-ce.0.el6.x86_64.rpm# 安装rpm-ivhgitlab-ce-12.4.2-ce.0.el6.x86_64.rpm4.4 核心配置修改GitLab 的主配置文件位于/etc/gitlab/gitlab.rb需要修改两处关键配置vim/etc/gitlab/gitlab.rb修改外部访问地址找到第 23 行左右修改external_url使用服务器的实际 IP 地址建议指定端口# 原配置需修改external_urlhttp://gitlab.example.com# 修改为使用服务器实际 IP指定端口 82external_urlhttp://192.168.100.153:82修改 Nginx 监听端口找到第 1112 行左右修改 Nginx 的监听端口与external_url中的端口保持一致# 原配置需修改# nginx[listen_port] nil# 修改为nginx[listen_port]824.5 重载配置与启动# 重载配置首次执行需要 5~10 分钟gitlab-ctl reconfigure# 启动 GitLab 服务gitlab-ctl restart验证服务状态gitlab-ctl status预期输出run: gitlab-workhorse: (pid 1234) 123s run: logrotate: (pid 1235) 123s run: nginx: (pid 1236) 123s run: postgresql: (pid 1237) 123s run: redis: (pid 1238) 123s run: sidekiq: (pid 1239) 123s run: unicorn: (pid 1240) 123s防火墙放行端口firewall-cmd--zonepublic --add-port82/tcp--permanentfirewall-cmd--reload4.6 首次访问与密码设置在浏览器中输入http://服务器IP:82首次访问会看到设置管理员密码的页面。┌──────────────────────────────────────────────┐ │ Welcome to GitLab │ │ │ │ Create admin account │ │ ┌──────────────────────────────────────┐ │ │ │ New password [________________] │ │ │ │ Confirm password [________________] │ │ │ │ [Change password] │ │ │ └──────────────────────────────────────┘ │ └──────────────────────────────────────────────┘操作步骤输入管理员密码建议abcd1234或更复杂的密码点击“Change password”使用用户名root和新设置的密码登录4.7 中文界面设置可选GitLab 默认界面为英文如果需要切换为中文点击右上角用户头像 →Settings→Preferences找到Localization→Language下拉选择Chinese, Simplified - 简体中文点击Save changes刷新页面⚠️ 常见问题排查问题可能原因解决方法页面无法访问防火墙未放行端口firewall-cmd --add-port82/tcp --permanent端口被占用其他服务占用了 82 端口修改external_url中的端口号SELinux 阻断SELinux 未关闭setenforce 0或配置 SELinux 策略内存不足GitLab 需要 4GB 内存增加服务器内存或使用 swap五、GitLab 基础操作——团队协作的第一步GitLab 安装完成后我们需要进行基本的配置才能开始团队协作。5.1 用户管理GitLab 支持创建两种类型的用户用户类型权限范围适用角色Regular只能访问属于自己的项目普通开发者Admin可以访问所有项目管理全局设置系统管理员创建普通用户步骤以管理员root身份登录点击顶部菜单管理员→用户→新用户填写用户信息姓名、用户名、邮箱点击创建用户编辑用户设置初始密码或通过邮件邀请用户设置5.2 组管理组Group是 GitLab 中管理项目和权限的核心单位。一个组可以包含多个项目权限在组层面统一管理。创建组步骤点击顶部菜单群组→新建群组填写组名称、组路径URL 中的标识设置可见性级别可见性含义适用场景Private只有组成员可见公司内部项目推荐Internal登录用户可见组织内部开放Public所有人可见开源项目 建议公司内部项目选择Private确保代码安全。5.3 权限模型GitLab 在组和项目中提供了 5 种角色权限角色权限范围适用角色Guest创建 Issue、发表评论不能读写代码产品经理、需求方Reporter可以克隆代码不能提交QA、测试工程师Developer克隆、开发、提交、Push普通开发者Maintainer创建项目、添加 Tag、保护分支、管理成员核心开发者、技术负责人Owner删除项目、迁移项目、管理组成员项目负责人 实战建议将成员加入组时选择Developer作为默认角色根据实际需要提升为 Maintainer。5.4 在组中创建项目操作步骤进入组页面点击新建项目填写项目名称如web_demo填写项目路径URL 中的标识设置可见性级别点击创建项目项目创建完成创建完成后GitLab 会显示项目地址和 Git 命令指引Project web_demo was successfully created. Command line instructions: Git global setup: git config --global user.name chen git config --global user.email chenqq.com Create a new repository: git clone http://192.168.100.153:82/chen_group/web_demo.git cd web_demo touch README.md git add README.md git commit -m add README git push -u origin master六、Git 基础与源码上传6.1 Git 在 Windows 上的安装下载地址https://gitforwindows.org/安装要点步骤推荐选项说明选择组件保持默认勾选 Git Bash安装 Git Bash 终端默认编辑器Use Vim默认或 Notepad初学者可保持默认初始分支名称保持main或master建议使用mainPATH 设置Git from command line…推荐可以在命令提示符中使用 gitHTTPS 后端OpenSSL默认使用标准的 SSL 库行尾转换Checkout Windows-style…推荐Windows 下推荐此选项终端模拟器MinTTY默认更好用的终端凭据辅助器Git Credential Manager Core简化 HTTPS 认证⚠️ 安装完成后Git Bash 可以在任意目录右键打开也可以从 Windows 开始菜单启动。6.2 Git 全局配置安装完成后需要配置用户名和邮箱这样每次提交时 Git 才知道是谁提交的。# 查看当前配置gitconfig--list# 设置全局用户名和邮箱gitconfig--globaluser.namechengitconfig--globaluser.emailchenqq.com6.3 IDEA 中集成 Git在 IntelliJ IDEA 中配置 Git 路径打开File→Settings或CtrlAltS搜索Git在Path to Git executable中选择 Git 安装路径如C:\Program Files\Git\bin\git.exe点击Test显示版本信息即配置成功6.4 将项目上传到 GitLab在 IDEA 中完成本地提交和远程推送步骤 1将项目添加到 Git 版本控制在 IDEA 中选择VCS→Enable Version Control Integration选择Git点击OKIDEA 右下角出现 Git 分支信息表示 Git 已启用步骤 2将文件添加到暂存区Add右键项目根目录 →Git→Add或使用快捷键选择文件后按CtrlAltA步骤 3提交到本地仓库Commit右键项目根目录 →Git→Commit Directory…填写提交信息如Initial commit点击Commit或Commit and Push步骤 4关联远程仓库在 GitLab 项目页面复制 HTTPS 或 SSH 地址在 IDEA 中Git→Manage Remotes…→Add填写远程名称origin粘贴远程仓库地址步骤 5推送到远程仓库PushGit→Push…或CtrlShiftK点击Push输入 GitLab 用户名和密码6.5 在 GitLab 中验证推送成功后在 GitLab 项目页面刷新即可看到上传的代码文件chen_group / web_demo ├── src/ ├── pom.xml ├── README.md └── ...提交历史点击Repository→Commits可以查看所有提交记录。七、常见问题排查指南问题现象可能原因解决方法GitLab 无法访问页面防火墙未开放端口firewall-cmd --add-port82/tcp --permanent firewall-cmd --reloadgit clone提示 403项目为 Private账号无权限用root账号或邀请用户加入项目git push提示 Authentication failed密码错误或未使用正确的认证方式HTTPS 方式使用 GitLab 账号密码SSH 方式配置公钥IDEA 中 Git 选项灰色项目未启用 Git 版本控制VCS → Enable Version Control Integration → Gitgit push被拒绝rejected远程有本地没有的提交先git pull合并再git pushGitLab 服务启动失败内存不足检查内存增加 swap 或增加物理内存八、本章知识点速查表类别概念/工具核心要点SDLC软件开发生命周期需求 → 设计 → 实现 → 测试 → 进化瀑布模型传统线性开发阶段严格顺序变更成本高敏捷开发迭代 增量快速交付、拥抱变化、客户参与CI持续集成频繁合并 自动构建 自动测试CD持续交付/部署一键部署、自动化流水线GitLab代码托管平台自建 GitHub支持 CI/CDGit版本控制工具分布式管理、分支策略权限模型5 种角色Guest/Reporter/Developer/Maintainer/Owner 总结本期作为 DevOps 系列的开篇我们完成了两件大事理解了 DevOps 的核心理念——从 SDLC 到瀑布模型再到敏捷开发和 CI/CD明白了“为什么 DevOps 是现代软件开发的标准实践”搭建了 GitLab 代码仓库——完成了从服务器部署、配置、启动到团队管理、代码上传的完整流程关键收获✅ 能够清晰区分瀑布模型和敏捷开发的核心差异✅ 理解 CI/CD 的基本概念和价值✅ 独立完成 GitLab 的安装和配置✅ 掌握用户/组/项目的创建和权限分配✅ 会用 Git 将本地代码推送到远程仓库动手验证清单验证项状态浏览器能打开 GitLab 登录页面☐root能正常登录☐成功创建了一个非管理员用户☐成功创建了一个组和一个项目☐本地 Git 配置了正确的用户名和邮箱☐本地代码成功推送到 GitLab 仓库☐GitLab 仓库中能看到提交记录和文件☐ 下期预告本期我们完成了 DevOps 的理念认知和 GitLab 代码仓库的搭建团队协作的“地基”已经打好。下一期第二期我们将正式进入CI/CD 流水线搭建——部署Jenkins这个 DevOps 工具链中最核心的自动化引擎。我们将从 Docker 部署 Jenkins 开始完成初始化配置、插件安装、JDK/Maven 全局配置、SSH 远程部署配置让 Jenkins 具备从代码仓库拉取代码并自动构建的能力。敬请期待本期DevOps 概述与 GitLab 部署到此结束。如果在操作过程中遇到任何问题欢迎在评论区留言讨论— Compiled and Authored by Whisky — July 23 rd, 2026
云原生 DevOps 工具链从入门到实战（第一期）——DevOps概述与GitLab部署——从理念到工具落地
发布时间：2026/7/24 3:32:07
云原生 DevOps 工具链从入门到实战第一期——DevOps概述与GitLab部署——从理念到工具落地更多云原生DevOps技能学习请戳这里云原生 DevOps 工具链从入门到实战我的主页AOwhisky这里有更多运维系统性知识整理和其他有趣内容欢迎与我一起探讨学习~ 引言从“写好代码”到“持续交付”在 Python 系列中我们学会了用代码解决问题——用 psutil 监控服务器、用 paramiko 批量执行命令、用 IPy 规划网络地址。你已经具备了“用 Python 做自动化”的能力。但当你把代码提交到公司仓库、和团队一起开发时新的问题出现了代码怎么和大家合并冲突了怎么办每次改完代码都要手动打包、部署、测试吗怎么保证代码质量怎么知道有没有引入 bug产品需要快速迭代但每次发布都像“拆弹”一样紧张……这些问题的答案指向一个更大的领域——DevOps开发运维一体化。 白话理解如果说 Python 系列是教你“造工具”那么 DevOps 系列就是教你“建工厂”——从原材料代码到成品线上服务的完整流水线。本期作为 DevOps 系列的开篇我们将一起完成两件事理解 DevOps 的核心理念以及搭建团队协作的基石——GitLab 代码仓库。— Compiled and Authored by Whisky — July 23 rd, 2026 本期目录软件开发生命周期SDLC瀑布模型 vs 敏捷开发持续集成 / 持续交付CI/CDGitLab 部署GitLab 基础操作——团队协作的第一步Git 基础与源码上传总结与知识点一览表正文一、软件开发生命周期SDLC1.1 什么是 SDLC软件开发生命周期Software Development Life CycleSDLC是软件从“想法”到“上线”再到“退役”的完整过程。它不是一个单一的活动而是由多个阶段组成的结构化流程。一个标准的 SDLC 包含以下五个阶段需求分析 → 设计 → 实现 → 测试 → 进化维护各阶段详解阶段核心目标主要交付物参与角色需求分析明确“做什么”收集和分析项目需求需求文档、可行性分析报告产品经理、需求分析师、客户设计确定“怎么做”制定系统架构和技术方案架构设计文档、数据库设计、接口文档系统架构师、技术负责人实现将设计转化为可运行的代码源代码、配置文件开发工程师测试验证代码的正确性和质量测试报告、Bug 列表测试工程师、QA进化持续维护、修复 Bug、增加新功能版本更新、运维报告运维工程师、开发工程师 白话理解SDLC 就像建房子的流程——先看地皮需求分析再画图纸设计然后施工队进场盖楼实现盖好后验收测试最后入住后的维修和装修进化。少了任何一步房子都可能出问题。1.2 为什么需要 SDLC标准化每个阶段有明确的输入和输出减少沟通成本质量控制测试阶段独立于开发阶段保证交付质量风险管理通过阶段性的评审尽早发现问题可追溯性每个阶段的文档记录了决策过程便于后期回溯二、瀑布模型 vs 敏捷开发2.1 瀑布模型Waterfall Model瀑布模型是最经典、最传统的软件开发模型得名于其“自上而下、单向流动”的结构——就像瀑布的水流一样只能从高处往低处流不能倒流。瀑布模型的六个阶段需求分析 → 系统设计 → 实现 → 集成测试 → 部署 → 维护 每个阶段必须完全完成后才能进入下一阶段优势优势说明简单易懂线性流程每个阶段的划分清晰明确阶段性检查每个阶段结束时有明确的里程碑和交付物文档完整每个阶段产生大量文档便于知识传承劣势劣势说明不适应性用户需求的变化难以在后期被接纳因为改动成本极高延迟反馈用户只有等到项目末期才能看到可运行的产品风险高文档过重大量的文档编写增加了工作量和维护成本缺乏灵活性线性结构导致开发周期长难以应对市场变化 白话理解瀑布模型就像“瀑布”——水从上往下流不能倒流。你用一年时间建了一栋大楼结果发现客户想要的是别墅而不是办公楼这时候已经没法改了。2.2 敏捷开发Agile Development敏捷开发是针对瀑布模型缺陷而提出的一套开发理念其核心是“迭代开发”和“增量开发”。何为迭代开发Iterative Development传统方式采用一个大周期如一年进行开发整个过程就是一次“大开发”迭代开发则将开发过程拆分成多个小周期如两周每次小开发都包含完整的开发流程需求、设计、编码、测试反复迭代。 比喻SpaceX 不是一开始就造 Falcon Heavy 重型火箭而是先造最简陋的 Falcon 1前三次发射都爆炸了第四次才成功。如果 SpaceX 不采用迭代开发它可能到现在还无法上天。每枚火箭都比上一枚更好这就是迭代。何为增量开发Incremental Development每次迭代交付一个用户可以感知的完整功能而不是交付“功能的碎片”。 比喻房产公司开发一个 10 栋楼的小区。增量开发是第一期交付 1 号楼完整功能第二期交付 2 号楼完整功能……而不是先建好所有楼的地基再建所有楼的骨架。敏捷开发的核心价值《敏捷宣言》价值观说明个体和互动高于 流程和工具人是第一位的沟通比工具更重要可工作的软件高于 详尽的文档能运行的代码比完美的文档更有价值客户合作高于 合同谈判与客户持续沟通而非只在签约时确定需求响应变化高于 遵循计划拥抱变化而非僵化地执行计划敏捷开发的 12 条原则精简版尽早、持续地交付有价值的软件欢迎需求变化即使在开发后期频繁交付数周到数月业务人员与开发者每日协同工作给团队足够的支持并相信他们能完成任务面对面的沟通最有效率可工作的软件是衡量进度的主要标准保持可持续的开发节奏持续关注技术卓越和良好设计简单性至关重要自组织团队产生最好的架构、需求和设计团队定期反思如何变得更有效瀑布模型 vs 敏捷开发对比对比维度瀑布模型敏捷开发开发方式线性顺序开发迭代式、增量式开发需求变化难以适应需求变化后期改动成本极高欢迎变化在每个迭代中可调整需求交付频率项目末期一次性交付每个迭代结束时交付可用的功能用户参与主要在需求和验收阶段参与全程持续参与客户代表在团队中文档要求大量文档每个阶段有完整的文档产出适度文档以可工作的软件为核心风险控制风险暴露在后期每个迭代都能发现和应对风险适用场景需求明确、变更少、规模适中的项目需求不明确、变化快、需要快速上市的产品 白话理解瀑布模型像“建大桥”——图纸必须一次画好开工后不能改敏捷开发像“做互联网产品”——每两周发一个新版本根据用户反馈不断调整越做越好。2.3 迭代开发 vs 增量开发补充澄清这两个概念是敏捷的核心但经常被混淆概念关注点示例迭代开发关注“时间维度”——开发过程分成多个小周期每次迭代 2 周不是一次大开发增量开发关注“功能维度”——每次交付一个完整功能第一期交付登录功能第二期交付支付功能两者通常结合使用用迭代的节奏做增量的开发。三、持续集成 / 持续交付CI/CD3.1 什么是 CI/CDCI/CD 是 DevOps 的核心实践它将敏捷开发的理念落实到工具和流程层面。缩写全称核心含义CIContinuous Integration持续集成频繁地将代码合并到主干并自动构建和测试CDContinuous Delivery持续交付每次代码变更都能自动部署到类生产环境CDContinuous Deployment持续部署通过自动化测试的变更自动部署到生产环境 白话理解CI 是“每天多次合并代码并自动检查”CD 是“每次合并后都能自动打包好随时可以上线”持续部署是“自动上线”。3.2 从代码提交到生产的完整流程1. 提交Commit ↓ 2. 测试第一轮自动化测试 ↓ 3. 构建Build编译 打包 ↓ 4. 测试第二轮集成测试/质量扫描 ↓ 5. 部署Deploy发布到服务器 ↓ 6. 回滚Rollback出错时快速恢复各阶段详解阶段说明自动化方式提交开发者向代码仓库提交代码触发钩子Git Hook测试第一轮自动化单元测试确保基础功能正常测试框架JUnit/TestNG构建将源码编译、打包成可执行文件Maven/Gradle测试第二轮集成测试、代码质量分析如 SonarQube质量分析工具部署将构建产物上传到生产服务器并运行脚本 编排工具Docker/K8s回滚出现问题时快速恢复到上一个稳定版本版本控制 自动化脚本3.3 持续集成的核心价值价值说明快速反馈代码提交后几分钟内就能知道是否通过测试降低风险问题越早发现修复成本越低提升质量每次提交都经过自动化测试质量有保障减少重复劳动构建、测试、部署全部自动化解放人力增强信心每次发布都经过完整流程验证不再“心惊胆战”3.4 核心工具链在 DevOps 工具链中本期涉及的基础工具及其定位如下工具定位本期涉及内容GitLab代码托管 CI/CD 一体化平台✅ 本期部署与配置JenkinsCI/CD 自动化服务器后续章节MavenJava 项目构建工具后续章节Docker容器化技术后续章节Kubernetes容器编排平台后续章节四、GitLab 部署4.1 GitLab 是什么GitLab 是一个基于 Git 的代码托管平台可以看作是“自己搭建的 GitHub”。它开源、免费社区版且支持 CI/CD 流水线、代码审查、问题跟踪等一体化功能。 白话理解GitLab 就是“公司内部的 GitHub”——代码不上传别人服务器全部掌握在自己手中。适合团队内部协作不用担心代码泄露。4.2 前置环境准备在安装 GitLab 之前需要先准备好服务器的操作系统环境。配置主机名与解析# 设置主机名根据实际修改hostnamectl set-hostname gitlab# 添加主机名解析echo127.0.0.1$(hostname)/etc/hosts安装依赖包GitLab 依赖policycoreutilsSELinux 管理、openssh-serverSSH 服务和postfix邮件通知。yum-yinstallpolicycoreutils openssh-server openssh-clients postfix启动 SSH 和 Postfix 服务systemctlenablesshd--nowsystemctlenablepostfix--now开放防火墙端口GitLab 需要开放 SSH 和 HTTP 服务端口。firewall-cmd --add-servicessh--permanentfirewall-cmd --add-servicehttp--permanentfirewall-cmd--reload4.3 下载与安装 GitLab# 下载 GitLab 安装包以 12.4.2 版本为例wgethttps://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el6/gitlab-ce-12.4.2-ce.0.el6.x86_64.rpm# 安装rpm-ivhgitlab-ce-12.4.2-ce.0.el6.x86_64.rpm4.4 核心配置修改GitLab 的主配置文件位于/etc/gitlab/gitlab.rb需要修改两处关键配置vim/etc/gitlab/gitlab.rb修改外部访问地址找到第 23 行左右修改external_url使用服务器的实际 IP 地址建议指定端口# 原配置需修改external_urlhttp://gitlab.example.com# 修改为使用服务器实际 IP指定端口 82external_urlhttp://192.168.100.153:82修改 Nginx 监听端口找到第 1112 行左右修改 Nginx 的监听端口与external_url中的端口保持一致# 原配置需修改# nginx[listen_port] nil# 修改为nginx[listen_port]824.5 重载配置与启动# 重载配置首次执行需要 5~10 分钟gitlab-ctl reconfigure# 启动 GitLab 服务gitlab-ctl restart验证服务状态gitlab-ctl status预期输出run: gitlab-workhorse: (pid 1234) 123s run: logrotate: (pid 1235) 123s run: nginx: (pid 1236) 123s run: postgresql: (pid 1237) 123s run: redis: (pid 1238) 123s run: sidekiq: (pid 1239) 123s run: unicorn: (pid 1240) 123s防火墙放行端口firewall-cmd--zonepublic --add-port82/tcp--permanentfirewall-cmd--reload4.6 首次访问与密码设置在浏览器中输入http://服务器IP:82首次访问会看到设置管理员密码的页面。┌──────────────────────────────────────────────┐ │ Welcome to GitLab │ │ │ │ Create admin account │ │ ┌──────────────────────────────────────┐ │ │ │ New password [________________] │ │ │ │ Confirm password [________________] │ │ │ │ [Change password] │ │ │ └──────────────────────────────────────┘ │ └──────────────────────────────────────────────┘操作步骤输入管理员密码建议abcd1234或更复杂的密码点击“Change password”使用用户名root和新设置的密码登录4.7 中文界面设置可选GitLab 默认界面为英文如果需要切换为中文点击右上角用户头像 →Settings→Preferences找到Localization→Language下拉选择Chinese, Simplified - 简体中文点击Save changes刷新页面⚠️ 常见问题排查问题可能原因解决方法页面无法访问防火墙未放行端口firewall-cmd --add-port82/tcp --permanent端口被占用其他服务占用了 82 端口修改external_url中的端口号SELinux 阻断SELinux 未关闭setenforce 0或配置 SELinux 策略内存不足GitLab 需要 4GB 内存增加服务器内存或使用 swap五、GitLab 基础操作——团队协作的第一步GitLab 安装完成后我们需要进行基本的配置才能开始团队协作。5.1 用户管理GitLab 支持创建两种类型的用户用户类型权限范围适用角色Regular只能访问属于自己的项目普通开发者Admin可以访问所有项目管理全局设置系统管理员创建普通用户步骤以管理员root身份登录点击顶部菜单管理员→用户→新用户填写用户信息姓名、用户名、邮箱点击创建用户编辑用户设置初始密码或通过邮件邀请用户设置5.2 组管理组Group是 GitLab 中管理项目和权限的核心单位。一个组可以包含多个项目权限在组层面统一管理。创建组步骤点击顶部菜单群组→新建群组填写组名称、组路径URL 中的标识设置可见性级别可见性含义适用场景Private只有组成员可见公司内部项目推荐Internal登录用户可见组织内部开放Public所有人可见开源项目 建议公司内部项目选择Private确保代码安全。5.3 权限模型GitLab 在组和项目中提供了 5 种角色权限角色权限范围适用角色Guest创建 Issue、发表评论不能读写代码产品经理、需求方Reporter可以克隆代码不能提交QA、测试工程师Developer克隆、开发、提交、Push普通开发者Maintainer创建项目、添加 Tag、保护分支、管理成员核心开发者、技术负责人Owner删除项目、迁移项目、管理组成员项目负责人 实战建议将成员加入组时选择Developer作为默认角色根据实际需要提升为 Maintainer。5.4 在组中创建项目操作步骤进入组页面点击新建项目填写项目名称如web_demo填写项目路径URL 中的标识设置可见性级别点击创建项目项目创建完成创建完成后GitLab 会显示项目地址和 Git 命令指引Project web_demo was successfully created. Command line instructions: Git global setup: git config --global user.name chen git config --global user.email chenqq.com Create a new repository: git clone http://192.168.100.153:82/chen_group/web_demo.git cd web_demo touch README.md git add README.md git commit -m add README git push -u origin master六、Git 基础与源码上传6.1 Git 在 Windows 上的安装下载地址https://gitforwindows.org/安装要点步骤推荐选项说明选择组件保持默认勾选 Git Bash安装 Git Bash 终端默认编辑器Use Vim默认或 Notepad初学者可保持默认初始分支名称保持main或master建议使用mainPATH 设置Git from command line…推荐可以在命令提示符中使用 gitHTTPS 后端OpenSSL默认使用标准的 SSL 库行尾转换Checkout Windows-style…推荐Windows 下推荐此选项终端模拟器MinTTY默认更好用的终端凭据辅助器Git Credential Manager Core简化 HTTPS 认证⚠️ 安装完成后Git Bash 可以在任意目录右键打开也可以从 Windows 开始菜单启动。6.2 Git 全局配置安装完成后需要配置用户名和邮箱这样每次提交时 Git 才知道是谁提交的。# 查看当前配置gitconfig--list# 设置全局用户名和邮箱gitconfig--globaluser.namechengitconfig--globaluser.emailchenqq.com6.3 IDEA 中集成 Git在 IntelliJ IDEA 中配置 Git 路径打开File→Settings或CtrlAltS搜索Git在Path to Git executable中选择 Git 安装路径如C:\Program Files\Git\bin\git.exe点击Test显示版本信息即配置成功6.4 将项目上传到 GitLab在 IDEA 中完成本地提交和远程推送步骤 1将项目添加到 Git 版本控制在 IDEA 中选择VCS→Enable Version Control Integration选择Git点击OKIDEA 右下角出现 Git 分支信息表示 Git 已启用步骤 2将文件添加到暂存区Add右键项目根目录 →Git→Add或使用快捷键选择文件后按CtrlAltA步骤 3提交到本地仓库Commit右键项目根目录 →Git→Commit Directory…填写提交信息如Initial commit点击Commit或Commit and Push步骤 4关联远程仓库在 GitLab 项目页面复制 HTTPS 或 SSH 地址在 IDEA 中Git→Manage Remotes…→Add填写远程名称origin粘贴远程仓库地址步骤 5推送到远程仓库PushGit→Push…或CtrlShiftK点击Push输入 GitLab 用户名和密码6.5 在 GitLab 中验证推送成功后在 GitLab 项目页面刷新即可看到上传的代码文件chen_group / web_demo ├── src/ ├── pom.xml ├── README.md └── ...提交历史点击Repository→Commits可以查看所有提交记录。七、常见问题排查指南问题现象可能原因解决方法GitLab 无法访问页面防火墙未开放端口firewall-cmd --add-port82/tcp --permanent firewall-cmd --reloadgit clone提示 403项目为 Private账号无权限用root账号或邀请用户加入项目git push提示 Authentication failed密码错误或未使用正确的认证方式HTTPS 方式使用 GitLab 账号密码SSH 方式配置公钥IDEA 中 Git 选项灰色项目未启用 Git 版本控制VCS → Enable Version Control Integration → Gitgit push被拒绝rejected远程有本地没有的提交先git pull合并再git pushGitLab 服务启动失败内存不足检查内存增加 swap 或增加物理内存八、本章知识点速查表类别概念/工具核心要点SDLC软件开发生命周期需求 → 设计 → 实现 → 测试 → 进化瀑布模型传统线性开发阶段严格顺序变更成本高敏捷开发迭代 增量快速交付、拥抱变化、客户参与CI持续集成频繁合并 自动构建 自动测试CD持续交付/部署一键部署、自动化流水线GitLab代码托管平台自建 GitHub支持 CI/CDGit版本控制工具分布式管理、分支策略权限模型5 种角色Guest/Reporter/Developer/Maintainer/Owner 总结本期作为 DevOps 系列的开篇我们完成了两件大事理解了 DevOps 的核心理念——从 SDLC 到瀑布模型再到敏捷开发和 CI/CD明白了“为什么 DevOps 是现代软件开发的标准实践”搭建了 GitLab 代码仓库——完成了从服务器部署、配置、启动到团队管理、代码上传的完整流程关键收获✅ 能够清晰区分瀑布模型和敏捷开发的核心差异✅ 理解 CI/CD 的基本概念和价值✅ 独立完成 GitLab 的安装和配置✅ 掌握用户/组/项目的创建和权限分配✅ 会用 Git 将本地代码推送到远程仓库动手验证清单验证项状态浏览器能打开 GitLab 登录页面☐root能正常登录☐成功创建了一个非管理员用户☐成功创建了一个组和一个项目☐本地 Git 配置了正确的用户名和邮箱☐本地代码成功推送到 GitLab 仓库☐GitLab 仓库中能看到提交记录和文件☐ 下期预告本期我们完成了 DevOps 的理念认知和 GitLab 代码仓库的搭建团队协作的“地基”已经打好。下一期第二期我们将正式进入CI/CD 流水线搭建——部署Jenkins这个 DevOps 工具链中最核心的自动化引擎。我们将从 Docker 部署 Jenkins 开始完成初始化配置、插件安装、JDK/Maven 全局配置、SSH 远程部署配置让 Jenkins 具备从代码仓库拉取代码并自动构建的能力。敬请期待本期DevOps 概述与 GitLab 部署到此结束。如果在操作过程中遇到任何问题欢迎在评论区留言讨论— Compiled and Authored by Whisky — July 23 rd, 2026
)
