DevOps 入门 CI/CD 从零开始

引言

大家好，今天想跟你们聊聊 CI/CD 这个话题。说实话，我刚工作那会儿，每次上线都提心吊胆的——手动打包、FTP 上传、SSH 进去重启服务，偶尔还会遇到环境不一致导致的奇怪问题。有一次深夜上线，我连续改了 5 次配置才搞定，当时就想：这样下去不行啊，有没有更靠谱的方式？

后来接触了 CI/CD，简直打开了新世界的大门。今天就把我的学习心得整理一下，希望能帮到想入门的朋友。我们不搞那些高大上的概念，就从最实用的角度聊聊怎么从零开始搭建一套简单的 CI/CD 流程。

什么是 CI/CD，别被缩写吓到

CI/CD 其实就是几个英文单词的缩写：Continuous Integration（持续集成）和 Continuous Delivery/Deployment（持续交付/部署）。听起来挺高大上，但说白了就是一句话：让代码从写好到上线整个过程自动化。

以前我们怎么干活？写代码 → 本地测试 → 手动打包 → 传到服务器 → 手动部署。每一步都可能出错，而且全是重复劳动。CI/CD 就是要把这些步骤变成自动化的流水线，你只需要 push 代码，剩下的事儿交给机器去办。

持续集成（CI）说的是：每次有人提交代码，系统自动拉取代码、跑测试、验证能不能编译通过。这就像有个 vigilant 的小助手，每次你提交代码就帮你检查一遍有没有问题。

持续交付（CD）是在 CI 的基础上更进一步：代码通过测试后，自动部署到测试环境或者预生产环境。持续部署就更猛了，直接部署到生产环境——当然这个需要更多保障措施。

搭建第一个 CI 流程

说了这么多，咱们来点实际的。我来演示一下怎么用 GitHub Actions 搭建一个最简单的 CI 流程。这东西免费而且配置简单，非常适合入门。

首先，你需要一个 GitHub 仓库。假设我们有一个 Python 项目，目录结构大概是这样的：

myproject/

├── .github/


│   └── workflows/


│       └── ci.yml


├── src/


│   └── main.py


├── tests/


│   └── test_main.py


└── requirements.txt

然后在 .github/workflows/ci.yml 里写配置：

name: CI Pipeline


on:


push:


branches: [ main ]


pull_request:


branches: [ main ]



jobs:


build:


runs-on: ubuntu-latest

    

steps:


- uses: actions/checkout@v4

    

- name: Set up Python


uses: actions/setup-python@v5


with:


python-version: '3.11'

    

- name: Install dependencies


run: |


pip install -r requirements.txt

    

- name: Run tests


run: |


pytest tests/

保存、推送代码，然后去 GitHub 的 Actions 页面看看，你会看到流水线正在跑。这就是你的第一个 CI 流程！以后每次 push 代码，它都会自动拉取代码、安装依赖、运行测试。

常见的 CI/CD 工具

市面上的 CI/CD 工具还挺多的，我简单介绍一下主流的几个：

GitHub Actions 刚才演示的这个，优点是跟 GitHub 深度集成，配置简单，，免费额度也够用。如果你的代码在 GitHub，这是个很自然的选择。 GitLab CI 如果你用 GitLab，那自带的 CI/CD 功能就很强大。配置文件叫 .gitlab-ci.yml，语法跟 GitHub Actions 差不多，而且 Runner 可以自己部署，灵活度更高。 Jenkins 老牌工具了，插件生态极其丰富，几乎什么需求都能满足。但配置相对复杂，上手门槛比前两个高一些。适合需要高度定制化的企业场景。 CircleCI 和 Travis CI 也是不错的选择，各有特色。CircleCI 配置简洁，Travis CI 以前很流行，现在感觉用的人少了一些。

我的建议是：个人项目或者小团队，从 GitHub Actions 开始；用 GitLab 的就直接用 GitLab CI；等遇到复杂需求再考虑 Jenkins。

持续部署其实没那么难

CI 搞定了，接下来聊聊 CD。很多朋友觉得部署到生产环境很危险，不敢自动化。其实只要做好以下几件事，自动化部署也可以很安全：

第一，区分环境。 至少要有开发环境、测试环境、生产环境。CI 通过后自动部署到测试环境，人工验证后再部署到生产环境。 第二，使用 Docker。 把应用和依赖打包成镜像，这样无论在哪台机器上跑都是一样的环境，杜绝"在我机器上能跑"的问题。 
FROM python:3.11-slim


WORKDIR /app



COPY requirements.txt .


RUN pip install -r requirements.txt



COPY . .



CMD ["python", "src/main.py"]
第三，配置回滚机制。 部署后监控一下，如果出问题能快速回滚到上一个版本。GitHub Actions 可以这样配置： 
- name: Deploy to Production

if: github.ref == 'refs/heads/main'


run: |


# 部署命令


echo "Deploying to production..."
第四，渐进式发布。 刚开始可以只部署到一小部分服务器，观察没问题再全量部署。Kubernetes 的 Rolling Update 就是干这个的。

总结

好啦，今天聊了这么多，我们来回顾一下：

CI/CD 其实没那么神秘，就是把以前手动干的那些重复工作自动化。入门的话，建议从 GitHub Actions 开始体验，先跑通一个 CI 流程，感受一下自动化的魅力。然后慢慢加入测试、部署，一步步完善你的流水线。

自动化带来的改变是巨大的：你会有更多时间写代码而不是做运维，上线不再需要熬夜，代码质量也会因为有自动化测试的保障而提升。

刚开始可能会遇到各种问题，这很正常。我建议从小项目开始尝试，踩坑了也不心疼。等熟练了再应用到生产环境，你会发现这一切都是值得的。

好了，今天的分享就到这里。如果有什么问题，欢迎在评论区留言讨论。我们下期再见！