linux ci/cd流水线核心是自动化“提交→验证→交付”，可从shell脚本起步，涵盖代码拉取、依赖安装、构建编译、自动化测试、打包归档、部署上线六阶段，失败即中断；支持git钩子、cron轮询、webhook三种触发方式，后续可演进至github actions、docker、ansible等专业工具。
构建 Linux 下的 CI/CD 流水线，核心是把“代码提交→验证→交付”这个过程自动化、可重复、可追溯。不需要一开始就上 Jenkins 或 GitLab Runner，从 Shell 脚本起步就能跑通关键逻辑，再逐步升级工具链。
明确流水线的六个基础阶段
无论用什么工具，一条能落地的流水线都绕不开以下环节，每个环节失败就中断，避免问题向后传递：
-
代码拉取：从 Git 仓库（如 GitHub、GitLab）检出指定分支最新代码，建议使用
git clone --depth=1加速 -
依赖安装：执行
npm install、pip install -r requirements.txt或mvn dependency:resolve，注意锁定版本（如package-lock.json） -
构建编译：运行
npm run build、mvn clean package或make，输出可部署产物（如 dist/ 目录、jar 包、Docker 镜像） -
自动化测试：包含单元测试（
npm test）、静态扫描（eslint、shellcheck）和简单集成检查（如端口连通性） -
打包归档：将产物压缩为 tar.gz，或构建 Docker 镜像并推送到私有 Registry（如
docker push my-registry/app:latest） -
部署上线：用
scp同步文件、rsync增量更新，或调用docker-compose up -d/kubectl apply完成服务启动
用 Shell 脚本快速启动最小可行流水线
适合中小项目或 VPS 环境，不依赖外部服务，直接在目标服务器上运行：
- 脚本开头加
set -e，确保任意命令失败立即退出 - 定义清晰变量：
APP_DIR="/opt/myapp"、REPO_URL="https://github.com/user/project.git"、BRANCH="main" - 每阶段后检查
$?，失败时记录日志并退出，例如：if [ $? -ne 0 ]; then echo "测试失败" >> deploy.log; exit 1; fi - 部署前先备份旧版本（如
cp -r $APP_DIR $APP_DIR.bak.$(date +%s)），支持快速回滚 - 日志统一写入
/var/log/ci-deploy.log，方便排查；可后续扩展邮件或 Telegram 通知
触发方式要贴合实际场景
脚本写好了，得有人“喊它干活”。三种常见且低门槛的方式：
-
Git 钩子：在远程仓库的
post-receive中调用部署脚本，适合自建 Git 服务（如 Gitea） -
Cron 定时轮询：每 2–5 分钟执行一次
git pull && ./ci-deploy.sh，简单但有延迟，适合内网或低频更新项目 -
Webhook 接收器：用轻量 HTTP 服务（如 Python 的
http.server或webhook工具）监听 GitHub/GitLab 的推送事件，校验签名后触发脚本，实时性强
后续演进的关键升级点
当脚本稳定运行后，可按需引入更专业的工具提升能力：
- 用 GitHub Actions 或 GitLab CI 替代本地脚本，实现构建与部署环境隔离，避免污染生产服务器
- 引入 Docker + docker-compose 封装应用与依赖，解决“在我机器上能跑”的问题
- 用 Ansible 管理多台服务器配置与部署，替代手工
scp和ssh命令 - 增加 健康检查 和 自动回滚：部署后调用
curl -f http://localhost:3000/health，失败则还原备份目录或镜像标签 - 接入 监控告警，比如部署完成发消息到企业微信，或失败时触发 Prometheus Alertmanager
