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

更多云原生DevOps技能学习请戳这里：云原生 DevOps 工具链从入门到实战

我的主页：AOwhisky，这里有更多运维系统性知识整理和其他有趣内容，欢迎与我一起探讨学习~

📖 引言：从“写好代码”到“持续交付”

在 Python 系列中，我们学会了用代码解决问题——用 psutil 监控服务器、用 paramiko 批量执行命令、用 IPy 规划网络地址。你已经具备了“用 Python 做自动化”的能力。

但当你把代码提交到公司仓库、和团队一起开发时，新的问题出现了：

• 代码怎么和大家合并？冲突了怎么办？
• 每次改完代码，都要手动打包、部署、测试吗？
• 怎么保证代码质量？怎么知道有没有引入 bug？
• 产品需要快速迭代，但每次发布都像“拆弹”一样紧张……

这些问题的答案，指向一个更大的领域——DevOps（开发运维一体化）。

💡 白话理解：如果说 Python 系列是教你“造工具”，那么 DevOps 系列就是教你“建工厂”——从原材料（代码）到成品（线上服务）的完整流水线。

本期作为 DevOps 系列的开篇，我们将一起完成两件事：理解 DevOps 的核心理念，以及搭建团队协作的基石——GitLab 代码仓库。

📑 本期目录

1. 软件开发生命周期（SDLC）
2. 瀑布模型 vs 敏捷开发
3. 持续集成 / 持续交付（CI/CD）
4. GitLab 部署
5. GitLab 基础操作——团队协作的第一步
6. Git 基础与源码上传
7. 总结与知识点一览表

正文

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

1.1 什么是 SDLC

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

一个标准的 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/CD）

3.1 什么是 CI/CD

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

缩写	全称	核心含义
CI	Continuous Integration	持续集成：频繁地将代码合并到主干，并自动构建和测试
CD	Continuous Delivery	持续交付：每次代码变更都能自动部署到类生产环境
CD	Continuous 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 一体化平台	✅ 本期部署与配置
Jenkins	CI/CD 自动化服务器	后续章节
Maven	Java 项目构建工具	后续章节
Docker	容器化技术	后续章节
Kubernetes	容器编排平台	后续章节

四、GitLab 部署

4.1 GitLab 是什么

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

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

4.2 前置环境准备

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

配置主机名与解析：

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

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

安装依赖包：

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

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

启动 SSH 和 Postfix 服务：

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

开放防火墙端口：

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

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

4.3 下载与安装 GitLab

# 下载 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，需要修改两处关键配置：

vim /etc/gitlab/gitlab.rb

修改外部访问地址：

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

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

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

修改 Nginx 监听端口：

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

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

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

4.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 --zone=public --add-port=82/tcp --permanent
firewall-cmd --reload

4.6 首次访问与密码设置

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

┌──────────────────────────────────────────────┐
│   Welcome to GitLab                          │
│                                              │
│   Create admin account                       │
│   ┌──────────────────────────────────────┐   │
│   │  New password   [________________]  │   │
│   │  Confirm password [________________]  │   │
│   │        [Change password]            │   │
│   └──────────────────────────────────────┘   │
└──────────────────────────────────────────────┘

操作步骤：

1. 输入管理员密码（建议 abcd1234 或更复杂的密码）
2. 点击“Change password”
3. 使用用户名 root 和新设置的密码登录

4.7 中文界面设置（可选）

GitLab 默认界面为英文，如果需要切换为中文：

1. 点击右上角用户头像 → Settings → Preferences
2. 找到 Localization → Language
3. 下拉选择 Chinese, Simplified - 简体中文
4. 点击 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	可以访问所有项目，管理全局设置	系统管理员

创建普通用户步骤：

1. 以管理员（root）身份登录
2. 点击顶部菜单 管理员 → 用户 → 新用户
3. 填写用户信息（姓名、用户名、邮箱）
4. 点击 创建用户
5. 编辑用户，设置初始密码（或通过邮件邀请用户设置）

5.2 组管理

组（Group）是 GitLab 中管理项目和权限的核心单位。一个组可以包含多个项目，权限在组层面统一管理。

创建组步骤：

1. 点击顶部菜单 群组 → 新建群组
2. 填写组名称、组路径（URL 中的标识）
3. 设置可见性级别：

可见性	含义	适用场景
Private	只有组成员可见	公司内部项目（推荐）
Internal	登录用户可见	组织内部开放
Public	所有人可见	开源项目

💡 建议：公司内部项目选择 Private，确保代码安全。

5.3 权限模型

GitLab 在组和项目中提供了 5 种角色权限：

角色	权限范围	适用角色
Guest	创建 Issue、发表评论，不能读写代码	产品经理、需求方
Reporter	可以克隆代码，不能提交	QA、测试工程师
Developer	克隆、开发、提交、Push	普通开发者
Maintainer	创建项目、添加 Tag、保护分支、管理成员	核心开发者、技术负责人
Owner	删除项目、迁移项目、管理组成员	项目负责人

💡 实战建议：将成员加入组时，选择 Developer 作为默认角色，根据实际需要提升为 Maintainer。

5.4 在组中创建项目

操作步骤：

1. 进入组页面，点击 新建项目
2. 填写项目名称（如 web_demo）
3. 填写项目路径（URL 中的标识）
4. 设置可见性级别
5. 点击 创建项目

项目创建完成：

创建完成后，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 "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 才知道是谁提交的。

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

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

6.3 IDEA 中集成 Git

在 IntelliJ IDEA 中配置 Git 路径：

1. 打开 File → Settings（或 Ctrl+Alt+S）
2. 搜索 Git
3. 在 Path to Git executable 中选择 Git 安装路径（如 C:\Program Files\Git\bin\git.exe）
4. 点击 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 项目页面刷新，即可看到上传的代码文件：

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 系列的开篇，我们完成了两件大事：

1. 理解了 DevOps 的核心理念——从 SDLC 到瀑布模型，再到敏捷开发和 CI/CD，明白了“为什么 DevOps 是现代软件开发的标准实践”
2. 搭建了 GitLab 代码仓库——完成了从服务器部署、配置、启动到团队管理、代码上传的完整流程

关键收获：

• ✅ 能够清晰区分瀑布模型和敏捷开发的核心差异
• ✅ 理解 CI/CD 的基本概念和价值
• ✅ 独立完成 GitLab 的安装和配置
• ✅ 掌握用户/组/项目的创建和权限分配
• ✅ 会用 Git 将本地代码推送到远程仓库

动手验证清单：

验证项	状态
浏览器能打开 GitLab 登录页面	☐
root 能正常登录	☐
成功创建了一个非管理员用户	☐
成功创建了一个组和一个项目	☐
本地 Git 配置了正确的用户名和邮箱	☐
本地代码成功推送到 GitLab 仓库	☐
GitLab 仓库中能看到提交记录和文件	☐

🔜 下期预告

本期我们完成了 DevOps 的理念认知和 GitLab 代码仓库的搭建，团队协作的“地基”已经打好。

下一期（第二期） ，我们将正式进入 CI/CD 流水线搭建——部署 Jenkins，这个 DevOps 工具链中最核心的自动化引擎。我们将从 Docker 部署 Jenkins 开始，完成初始化配置、插件安装、JDK/Maven 全局配置、SSH 远程部署配置，让 Jenkins 具备从代码仓库拉取代码并自动构建的能力。敬请期待！

---

本期（DevOps 概述与 GitLab 部署）到此结束。 如果在操作过程中遇到任何问题，欢迎在评论区留言讨论！