CI/CD 详细使用教程

CI/CD 是现代软件开发中至关重要的实践，它代表持续集成（Continuous Integration）和持续部署（Continuous Deployment）或持续交付（Continuous Delivery）。本教程将 guiding 您了解 CI/CD 的核心概念、工作流程以及如何在实际项目中落地。

什么是持续集成（CI）

持续集成是指开发人员频繁地将代码集成到共享仓库中。每次集成都会通过自动化的构建和测试来验证，以便尽早发现错误。核心目标是减少集成冲突，提高代码质量。

什么是持续部署与交付（CD）

持续交付确保代码在经过测试后可以随时可靠地发布到生产环境。持续部署则更进一步，将通过所有测试的代码自动部署到生产环境，无需人工干预。这两者共同构成了自动化发布流水线。

CI/CD 的核心价值

提高效率：自动化重复任务，减少人工操作时间。
降低风险：小步快跑，每次变更范围小，出现问题容易回滚。
快速反馈：开发人员能迅速得知代码构建和测试的结果。
质量保证：强制通过测试才能进入下一阶段，确保交付质量。

主流 CI/CD 工具介绍

市面上有多种工具可供选择，您可以根据团队技术栈进行选择：

Jenkins：开源灵活，插件生态丰富，适合复杂定制需求。
GitLab CI：与 GitLab 代码仓库深度集成，配置简单，使用方便。
GitHub Actions：原生集成于 GitHub，适合开源项目及托管在 GitHub 上的私有项目。
CircleCI：云端服务，配置简洁，支持多种语言环境。

基础工作流程搭建

一个标准的 CI/CD 流水线通常包含以下几个阶段：

代码提交：开发人员将代码推送到版本控制系统（如 Git）。
触发构建：代码推送动作触发 CI 服务器开始工作。
依赖安装：系统自动安装项目所需的依赖包。
代码编译：将源代码编译为可执行文件或 artifacts。
自动化测试：运行单元测试、集成测试等验证代码逻辑。
代码扫描：进行静态代码分析，检查安全漏洞和规范。
构建镜像：如果是容器化部署，此处构建 Docker 镜像。
部署环境：将应用部署到测试环境或生产环境。

简单配置示例

以下是一个基于 GitHub Actions 的简单配置文件示例，展示了如何运行测试和构建：

name: CI Pipeline

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Run tests
        run: npm test
      - name: Build project
        run: npm run build

最佳实践建议

为了充分发挥 CI/CD 的优势，建议遵循以下原则：

保持构建快速：优化测试和构建脚本，确保流水线能在几分钟内完成。
测试覆盖率高：确保自动化测试覆盖核心业务逻辑，避免漏测。
单一来源真理：所有配置代码化（Infrastructure as Code），存放在版本控制中。
失败即停止：一旦任何阶段失败，立即停止流水线并通知相关人员。
定期维护：定期更新工具和依赖，修复已知漏洞。

常见问题与排查

在使用初期，您可能会遇到构建失败或部署超时的问题。首先检查日志输出，定位错误阶段。如果是环境依赖问题，尝试清理缓存或重新安装依赖。如果是网络问题，检查服务器连通性及权限配置。保持日志清晰可读有助于快速定位问题根源。

总结

实施 CI/CD 是一个循序渐进的过程。建议从简单的自动化构建开始，逐步加入测试、扫描和部署环节。通过不断迭代优化流水线，团队将获得更高的交付速度和更稳定的产品质量。希望本教程能帮助您顺利开启自动化运维之旅。

告别手动复制粘贴：我们如何实现 Windows 环境下的全自动化部署

摘要： 每次发布新版本都要手动停止服务、复制文件、重启程序？在这篇文章中，我们将分享如何利用 GitHub Actions 和自托管 Runner (Self-hosted Runner) 构建一条流畅的 Windows 到 Windows CI/CD 流水线，彻底告别繁琐的手动部署。

1. 曾经的痛点：手动部署的“黑暗时代”

在过去的开发周期中，每次要在测试机或生产机上更新我们的 Windows 桌面软件（或后台服务），流程大概是这样的：

在开发机上编译打包。
将几十 MB 甚至上百 MB 的安装包或压缩包通过微信、网盘或共享文件夹传到目标机器。
远程登录目标机器。
手动打开任务管理器，杀掉旧版本的进程。
解压新文件，覆盖旧文件。
重新启动程序，祈祷一切正常运行。

这不仅耗时耗力，而且极其容易出错（比如漏掉配置文件、忘记关闭旧进程导致文件被占用）。随着迭代速度的加快，这种“刀耕火种”的部署方式已经成为了团队效率的最大瓶颈。

2. 破局思路：引入 CI/CD 与自托管 Runner

为了解决这个问题，我们决定引入自动化流水线。考虑到我们的开发环境和目标环境都是 Windows，并且代码托管在支持 CI/CD 的平台上，我们最终敲定了 “云端触发 + 本地自托管 Runner 执行” 的架构。

核心思路很简单：

开发端： 开发者只需专注于写代码，完成后执行 git push。
云端桥梁： 代码仓库监听到提交后，生成部署指令，下发给目标机器。
目标端： 目标机器上安装了一个后台服务（Runner），它接收指令后，自动在本地拉取代码、编译、替换文件并重启应用。

3. 核心实践：部署流水线的关键步骤

我们在目标 Windows 机器上配置了 Actions Runner，并将其注册为 Windows 服务以保证常驻运行。接下来，我们编写了流水线脚本，主要包含以下几个关键自动化步骤：

自动化清理与准备： 脚本首先会静默停止正在运行的旧版本进程 Stop-Process -Name "MyApp" -ErrorAction SilentlyContinue，确保文件解除占用。
自动化构建： Runner 直接在目标机器上拉取最新 main 分支的代码，并执行编译命令，生成最新的二进制文件。
自动化覆盖： 使用 PowerShell 脚本将编译好的产物精准复制并覆盖到软件的实际运行目录中。
自动化启动： 最后，脚本拉起新版本的可执行文件，整个过程在几秒钟内无缝完成。

4. 取得的收益

这条简单的 CI/CD 流水线落地后，给我们带来了肉眼可见的改变：

🚀 效率飙升： 部署时间从过去的 10 分钟缩短到了 1 分钟以内，彻底解放了开发人员的双手。
🛡️ 零人为失误： 标准化的脚本代替了人工操作，再也没有出现过“忘了覆盖某个动态链接库”这种低级错误。
🔄 快速迭代： 真正实现了“代码一推，新版就绪”，团队可以更专注于业务逻辑的开发，而不是被运维琐事牵绊。

5. 结语

虽然 Windows 环境下的持续集成/持续部署在配置上可能比纯 Linux 环境稍显繁琐，但通过合理利用自托管 Runner，我们依然可以获得极致的自动化体验。如果你的团队也正在忍受手动部署的折磨，不妨花半天时间把这套流程搭建起来，这绝对是一笔稳赚不赔的投资！