GitHub Actions

Docker CI/CD 要解决什么问题 前面的 Docker 系列已经介绍了 Dockerfile、Docker Compose、镜像构建、镜像 Push 以及 Harbor 私有镜像仓库。 如果每次发布都手动执行： git pull docker build -t registry.example.com/backend/api:v1.0.0 . docker push registry.example.com/backend/api:v1.0.0 ssh server docker pull registry.example.com/backend/api:v1.0.0 docker compose up -d 项目规模较小时问题不大，但随着服务数量增加，手工发布会逐渐暴露出几个问题： 容易漏执行步骤。 镜像 Tag 容易写错。 测试和生产环境操作不一致。 发布过程缺少统一记录。 无法方便地回滚。 开发人员需要直接登录生产服务器。 发布效率随着项目数量增加而下降。 CI/CD 的核心目标，就是把这些重复操作交给自动化系统完成。 一个典型的 Docker CI/CD 流程如下： Git Push │ ▼ CI Pipeline │ ├── Checkout ├── Test ├── Build Image ├── Tag Image └── Push Image │ ▼ Harbor │ ▼ Deploy │ ▼ Production 最终开发人员只需要：...

GitHub 不只是代码托管平台 很多开发者使用 GitHub 时，主要把它当成远程 Git 仓库： git push ↓ GitHub 但对于一个真正需要长期维护的项目来说，代码仓库只是 GitHub 的一部分。 一个完整的软件开发过程通常还包括： 需求 ↓ Issue ↓ 开发 ↓ Pull Request ↓ Code Review ↓ CI ↓ Merge ↓ Release ↓ 用户 GitHub 恰好把这条链路中的多个环节连接起来。 其中： Issue 负责描述和跟踪工作； Pull Request 负责提交代码变更； Code Review 负责验证代码； Actions 负责自动化检查； Ruleset 负责约束仓库规则； Release 负责向用户交付稳定版本。 GitHub 官方也将 Pull Request 模板、Code Owners、受保护分支和 Rulesets 作为标准化 Pull Request 和保护重要分支的重要工具。(GitHub：管理和标准化 Pull Request) 因此，GitHub 工程化的核心并不是「会使用多少 GitHub 功能」，而是建立一条可追踪、可审查、可自动化、可发布的软件交付流程。 Issue：把需求和问题变成可追踪任务 Issue 是项目管理的起点。...

GitHub Actions 是什么 GitHub Actions 是 GitHub 提供的 CI/CD 自动化平台，可以根据代码仓库中的事件自动执行构建、测试、发布和部署任务。 例如，一个 PHP 项目可以设计成： 开发者 │ │ git push ▼ GitHub Repository │ │ push event ▼ GitHub Actions │ ├── Checkout ├── Install Dependencies ├── Run Tests ├── Docker Build ├── Docker Push └── Deploy │ ▼ Production GitHub 官方将 Actions 的核心组成划分为 Workflow、Job、Step、Runner 和 Action。一个 Workflow 可以包含一个或多个 Job，每个 Job 又由多个 Step 组成。Job 默认可以并行执行，也可以通过依赖关系串联起来。(GitHub Actions 官方文档) GitHub Actions 官方文档 GitHub Actions 最大的价值并不是「帮你执行几个 Shell 命令」，而是把代码仓库、自动化测试、镜像构建、镜像仓库和部署环境连接起来。...