云原生 DevOps 工具链从入门到实战（第一期）——DevOps概述与GitLab部署——从理念到工具落地

云原生 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/CD）
GitLab 部署
GitLab 基础操作------团队协作的第一步
Git 基础与源码上传
总结与知识点一览表

正文

一、软件开发生命周期（SDLC）

1.1 什么是 SDLC

软件开发生命周期（Software Development Life Cycle，SDLC）是软件从"想法"到"上线"再到"退役"的完整过程。它不是一个单一的活动，而是由多个阶段组成的结构化流程。

一个标准的 SDLC 包含以下五个阶段：

text 复制代码

需求分析 → 设计 → 实现 → 测试 → 进化（维护）

各阶段详解：

阶段	核心目标	主要交付物	参与角色
需求分析	明确"做什么"，收集和分析项目需求	需求文档、可行性分析报告	产品经理、需求分析师、客户
设计	确定"怎么做"，制定系统架构和技术方案	架构设计文档、数据库设计、接口文档	系统架构师、技术负责人
实现	将设计转化为可运行的代码	源代码、配置文件	开发工程师
测试	验证代码的正确性和质量	测试报告、Bug 列表	测试工程师、QA
进化	持续维护、修复 Bug、增加新功能	版本更新、运维报告	运维工程师、开发工程师

💡 白话理解：SDLC 就像建房子的流程------先看地皮（需求分析），再画图纸（设计），然后施工队进场盖楼（实现），盖好后验收（测试），最后入住后的维修和装修（进化）。少了任何一步，房子都可能出问题。

1.2 为什么需要 SDLC

标准化：每个阶段有明确的输入和输出，减少沟通成本
质量控制：测试阶段独立于开发阶段，保证交付质量
风险管理：通过阶段性的评审，尽早发现问题
可追溯性：每个阶段的文档记录了决策过程，便于后期回溯

二、瀑布模型 vs 敏捷开发

2.1 瀑布模型（Waterfall Model）

瀑布模型是最经典、最传统的软件开发模型，得名于其"自上而下、单向流动"的结构------就像瀑布的水流一样，只能从高处往低处流，不能倒流。

瀑布模型的六个阶段：

text 复制代码

需求分析 → 系统设计 → 实现 → 集成测试 → 部署 → 维护
（每个阶段必须完全完成后，才能进入下一阶段）

优势：

优势	说明
简单易懂	线性流程，每个阶段的划分清晰明确
阶段性检查	每个阶段结束时有明确的里程碑和交付物
文档完整	每个阶段产生大量文档，便于知识传承

劣势：

劣势	说明
不适应性	用户需求的变化难以在后期被接纳，因为改动成本极高
延迟反馈	用户只有等到项目末期才能看到可运行的产品，风险高
文档过重	大量的文档编写增加了工作量和维护成本
缺乏灵活性	线性结构导致开发周期长，难以应对市场变化

💡 白话理解：瀑布模型就像"瀑布"------水从上往下流，不能倒流。你用一年时间建了一栋大楼，结果发现客户想要的是别墅而不是办公楼，这时候已经没法改了。

2.2 敏捷开发（Agile Development）

敏捷开发是针对瀑布模型缺陷而提出的一套开发理念，其核心是 "迭代开发" 和 "增量开发"。

何为迭代开发（Iterative Development）：

传统方式采用一个大周期（如一年）进行开发，整个过程就是一次"大开发"；迭代开发则将开发过程拆分成多个小周期（如两周），每次小开发都包含完整的开发流程（需求、设计、编码、测试），反复迭代。

💡 比喻：SpaceX 不是一开始就造 Falcon Heavy 重型火箭，而是先造最简陋的 Falcon 1，前三次发射都爆炸了，第四次才成功。如果 SpaceX 不采用迭代开发，它可能到现在还无法上天。每枚火箭都比上一枚更好，这就是迭代。

何为增量开发（Incremental Development）：

每次迭代交付一个用户可以感知的完整功能，而不是交付"功能的碎片"。

💡 比喻：房产公司开发一个 10 栋楼的小区。增量开发是第一期交付 1 号楼（完整功能），第二期交付 2 号楼（完整功能）......而不是先建好所有楼的地基，再建所有楼的骨架。

敏捷开发的核心价值（《敏捷宣言》）：

价值观	说明
个体和互动高于流程和工具	人是第一位的，沟通比工具更重要
可工作的软件高于详尽的文档	能运行的代码比完美的文档更有价值
客户合作高于合同谈判	与客户持续沟通，而非只在签约时确定需求
响应变化高于遵循计划	拥抱变化，而非僵化地执行计划

敏捷开发的 12 条原则（精简版）：

尽早、持续地交付有价值的软件
欢迎需求变化，即使在开发后期
频繁交付（数周到数月）
业务人员与开发者每日协同工作
给团队足够的支持，并相信他们能完成任务
面对面的沟通最有效率
可工作的软件是衡量进度的主要标准
保持可持续的开发节奏
持续关注技术卓越和良好设计
简单性至关重要
自组织团队产生最好的架构、需求和设计
团队定期反思如何变得更有效

瀑布模型 vs 敏捷开发对比：

对比维度	瀑布模型	敏捷开发
开发方式	线性顺序开发	迭代式、增量式开发
需求变化	难以适应需求变化，后期改动成本极高	欢迎变化，在每个迭代中可调整需求
交付频率	项目末期一次性交付	每个迭代结束时交付可用的功能
用户参与	主要在需求和验收阶段参与	全程持续参与（客户代表在团队中）
文档要求	大量文档，每个阶段有完整的文档产出	适度文档，以可工作的软件为核心
风险控制	风险暴露在后期	每个迭代都能发现和应对风险
适用场景	需求明确、变更少、规模适中的项目	需求不明确、变化快、需要快速上市的产品

💡 白话理解：瀑布模型像"建大桥"------图纸必须一次画好，开工后不能改；敏捷开发像"做互联网产品"------每两周发一个新版本，根据用户反馈不断调整，越做越好。

2.3 迭代开发 vs 增量开发（补充澄清）

这两个概念是敏捷的核心，但经常被混淆：

概念	关注点	示例
迭代开发	关注"时间维度"------开发过程分成多个小周期	每次迭代 2 周，不是一次大开发
增量开发	关注"功能维度"------每次交付一个完整功能	第一期交付登录功能，第二期交付支付功能

两者通常结合使用：用迭代的节奏，做增量的开发。

三、持续集成 / 持续交付（CI/CD）

3.1 什么是 CI/CD

CI/CD 是 DevOps 的核心实践，它将敏捷开发的理念落实到工具和流程层面。

缩写	全称	核心含义
CI	Continuous Integration	持续集成：频繁地将代码合并到主干，并自动构建和测试
CD	Continuous Delivery	持续交付：每次代码变更都能自动部署到类生产环境
CD	Continuous Deployment	持续部署：通过自动化测试的变更自动部署到生产环境

💡 白话理解：CI 是"每天多次合并代码并自动检查"，CD 是"每次合并后都能自动打包好，随时可以上线"，持续部署是"自动上线"。

3.2 从代码提交到生产的完整流程

text 复制代码

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 一体化平台	✅ 本期部署与配置
Jenkins	CI/CD 自动化服务器	后续章节
Maven	Java 项目构建工具	后续章节
Docker	容器化技术	后续章节
Kubernetes	容器编排平台	后续章节

四、GitLab 部署

4.1 GitLab 是什么

GitLab 是一个基于 Git 的代码托管平台，可以看作是"自己搭建的 GitHub"。它开源、免费（社区版），且支持 CI/CD 流水线、代码审查、问题跟踪等一体化功能。

💡 白话理解：GitLab 就是"公司内部的 GitHub"------代码不上传别人服务器，全部掌握在自己手中。适合团队内部协作，不用担心代码泄露。

4.2 前置环境准备

在安装 GitLab 之前，需要先准备好服务器的操作系统环境。

配置主机名与解析：

bash 复制代码

# 设置主机名（根据实际修改）
hostnamectl set-hostname gitlab

# 添加主机名解析
echo "127.0.0.1 $(hostname)" >> /etc/hosts

安装依赖包：

GitLab 依赖 policycoreutils（SELinux 管理）、openssh-server（SSH 服务）和 postfix（邮件通知）。

bash 复制代码

yum -y install policycoreutils openssh-server openssh-clients postfix

启动 SSH 和 Postfix 服务：

bash 复制代码

systemctl enable sshd --now
systemctl enable postfix --now

开放防火墙端口：

GitLab 需要开放 SSH 和 HTTP 服务端口。

bash 复制代码

firewall-cmd --add-service=ssh --permanent
firewall-cmd --add-service=http --permanent
firewall-cmd --reload

4.3 下载与安装 GitLab

bash 复制代码

# 下载 GitLab 安装包（以 12.4.2 版本为例）
wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el6/gitlab-ce-12.4.2-ce.0.el6.x86_64.rpm

# 安装
rpm -ivh gitlab-ce-12.4.2-ce.0.el6.x86_64.rpm

4.4 核心配置修改

GitLab 的主配置文件位于 /etc/gitlab/gitlab.rb，需要修改两处关键配置：

bash 复制代码

vim /etc/gitlab/gitlab.rb

修改外部访问地址：

找到第 23 行左右，修改 external_url，使用服务器的实际 IP 地址（建议指定端口）：

ruby 复制代码

# 原配置（需修改）
external_url 'http://gitlab.example.com'

# 修改为（使用服务器实际 IP，指定端口 82）
external_url 'http://192.168.100.153:82'

修改 Nginx 监听端口：

找到第 1112 行左右，修改 Nginx 的监听端口，与 external_url 中的端口保持一致：

ruby 复制代码

# 原配置（需修改）
# nginx['listen_port'] = nil

# 修改为
nginx['listen_port'] = 82

4.5 重载配置与启动

bash 复制代码

# 重载配置（首次执行需要 5~10 分钟）
gitlab-ctl reconfigure

# 启动 GitLab 服务
gitlab-ctl restart

验证服务状态：

bash 复制代码

gitlab-ctl status

预期输出：

text 复制代码

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

防火墙放行端口：

bash 复制代码

firewall-cmd --zone=public --add-port=82/tcp --permanent
firewall-cmd --reload

4.6 首次访问与密码设置

在浏览器中输入 http://服务器IP:82，首次访问会看到设置管理员密码的页面。

text 复制代码

┌──────────────────────────────────────────────┐
│   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-port=82/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 命令指引：

text 复制代码

Project web_demo was successfully created.

Command line instructions:

Git global setup:
  git config --global user.name "chen"
  git config --global user.email "chen@qq.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`	建议使用 `main`
PATH 设置	Git from command line...（推荐）	可以在命令提示符中使用 git
HTTPS 后端	OpenSSL（默认）	使用标准的 SSL 库
行尾转换	Checkout Windows-style...（推荐）	Windows 下推荐此选项
终端模拟器	MinTTY（默认）	更好用的终端
凭据辅助器	Git Credential Manager Core	简化 HTTPS 认证

⚠️ 安装完成后：Git Bash 可以在任意目录右键打开，也可以从 Windows 开始菜单启动。

6.2 Git 全局配置

安装完成后，需要配置用户名和邮箱，这样每次提交时 Git 才知道是谁提交的。

bash 复制代码

# 查看当前配置
git config --list

# 设置全局用户名和邮箱
git config --global user.name "chen"
git config --global user.email "chen@qq.com"

6.3 IDEA 中集成 Git

在 IntelliJ IDEA 中配置 Git 路径：

打开 File → Settings （或 Ctrl+Alt+S）
搜索 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 ，点击 OK
IDEA 右下角出现 Git 分支信息，表示 Git 已启用

步骤 2：将文件添加到暂存区（Add）

右键项目根目录 → Git → Add
或使用快捷键：选择文件后按 Ctrl+Alt+A

步骤 3：提交到本地仓库（Commit）

右键项目根目录 → Git → Commit Directory...
填写提交信息（如 Initial commit）
点击 Commit 或 Commit and Push

步骤 4：关联远程仓库

在 GitLab 项目页面复制 HTTPS 或 SSH 地址
在 IDEA 中：Git → Manage Remotes... → Add
填写远程名称 origin，粘贴远程仓库地址

步骤 5：推送到远程仓库（Push）

Git → Push... （或 Ctrl+Shift+K）
点击 Push，输入 GitLab 用户名和密码

6.5 在 GitLab 中验证

推送成功后，在 GitLab 项目页面刷新，即可看到上传的代码文件：

text 复制代码

chen_group / web_demo
  ├── src/
  ├── pom.xml
  ├── README.md
  └── ...

提交历史：

点击 Repository → Commits，可以查看所有提交记录。

七、常见问题排查指南

问题现象	可能原因	解决方法
GitLab 无法访问页面	防火墙未开放端口	`firewall-cmd --add-port=82/tcp --permanent && firewall-cmd --reload`
`git clone` 提示 403	项目为 Private，账号无权限	用 `root` 账号或邀请用户加入项目
`git push` 提示 Authentication failed	密码错误或未使用正确的认证方式	HTTPS 方式使用 GitLab 账号密码；SSH 方式配置公钥
IDEA 中 Git 选项灰色	项目未启用 Git 版本控制	VCS → Enable Version Control Integration → Git
`git push` 被拒绝（rejected）	远程有本地没有的提交	先 `git pull` 合并，再 `git push`
GitLab 服务启动失败	内存不足	检查内存，增加 swap 或增加物理内存

八、本章知识点速查表

类别	概念/工具	核心要点
SDLC	软件开发生命周期	需求 → 设计 → 实现 → 测试 → 进化
瀑布模型	传统线性开发	阶段严格顺序，变更成本高
敏捷开发	迭代 + 增量	快速交付、拥抱变化、客户参与
CI	持续集成	频繁合并 + 自动构建 + 自动测试
CD	持续交付/部署	一键部署、自动化流水线
GitLab	代码托管平台	自建 GitHub，支持 CI/CD
Git	版本控制工具	分布式管理、分支策略
权限模型	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