|
| 1 | +# DevOps 自动化专家 - 核心经验总结 |
| 2 | + |
| 3 | +**角色职责**: 负责 GitHub Actions CI/CD 流水线设计、跨平台构建、自动化发布和代码质量检查 |
| 4 | + |
| 5 | +## ✅ 已完成任务总结 |
| 6 | + |
| 7 | +### 1. GitHub Actions CI/CD 流水线设计和实现 |
| 8 | +- ✅ 创建了完整的 CI 流水线 (`.github/workflows/ci.yml`) |
| 9 | +- ✅ 支持跨平台构建验证 (Windows/Linux/macOS) |
| 10 | +- ✅ 集成了 .NET 9.0 支持和 AOT 发布验证 |
| 11 | +- ✅ 基于 push 和 pull request 触发 |
| 12 | + |
| 13 | +### 2. 跨平台应用程序自动化构建 |
| 14 | +- ✅ 实现了基于 Tag 的自动化发布流水线 (`.github/workflows/release.yml`) |
| 15 | +- ✅ 支持三大平台:Windows (win-x64)、Linux (linux-x64)、macOS (osx-x64) |
| 16 | +- ✅ 使用 PublishAot=true 进行 AOT 编译 |
| 17 | +- ✅ 自动重命名可执行文件为平台特定名称 |
| 18 | + |
| 19 | +### 3. 自动化发布和版本管理 |
| 20 | +- ✅ 集成了 dotnetCampus.TagToVersion 工具 |
| 21 | +- ✅ 版本号自动从 Git Tag 提取并写入 Version.props |
| 22 | +- ✅ 支持预发布版本识别 (alpha/beta/rc) |
| 23 | +- ✅ 自动创建 GitHub Releases 并上传构建产物 |
| 24 | + |
| 25 | +### 4. 代码质量检查和自动化测试集成 |
| 26 | +- ✅ 创建了代码质量检查流水线 (`.github/workflows/code-quality.yml`) |
| 27 | +- ✅ 集成了 CodeQL 安全扫描 |
| 28 | +- ✅ 添加了依赖项审查 (Dependency Review) |
| 29 | +- ❌ 代码格式检查已移除(团队尚未统一 .editorconfig 标准) |
| 30 | + |
| 31 | +### 5. 依赖项安全扫描和更新 |
| 32 | +- ✅ 创建了自动化依赖更新流水线 (`.github/workflows/dependency-update.yml`) |
| 33 | +- ✅ 每周一自动检查过期的 NuGet 包 |
| 34 | +- ✅ 自动创建 PR 进行依赖更新 |
| 35 | + |
| 36 | +### 6. 基础设施即代码 |
| 37 | +- ❌ EditorConfig 文件已删除(团队尚未统一代码格式标准) |
| 38 | +- ✅ 设置了 CHANGELOG.md 模板 |
| 39 | +- ✅ 在 README.md 中添加了 CI 状态徽章 |
| 40 | + |
| 41 | +## 🔧 核心技术要点 |
| 42 | + |
| 43 | +### GitHub Actions 最佳实践 |
| 44 | +```yaml |
| 45 | +# 1. 使用最新版本的 Actions |
| 46 | +- uses: actions/checkout@v4 |
| 47 | +- uses: actions/setup-dotnet@v4 |
| 48 | + |
| 49 | +# 2. 跨平台路径处理 |
| 50 | +- name: Publish (Windows) |
| 51 | + if: matrix.os == 'windows-latest' |
| 52 | + run: dotnet publish .\src\DotNetCampus.Terminal\ -p:PublishAot=true -r ${{ matrix.runtime }} |
| 53 | + |
| 54 | +- name: Publish (Unix) |
| 55 | + if: matrix.os != 'windows-latest' |
| 56 | + run: dotnet publish ./src/DotNetCampus.Terminal/ -p:PublishAot=true -r ${{ matrix.runtime }} |
| 57 | + |
| 58 | +# 3. 条件执行和矩阵策略 |
| 59 | +strategy: |
| 60 | + matrix: |
| 61 | + include: |
| 62 | + - os: windows-latest |
| 63 | + runtime: win-x64 |
| 64 | + artifact-name: DotNetCampus.Terminal-win-x64.exe |
| 65 | +``` |
| 66 | +
|
| 67 | +### 版本管理策略 |
| 68 | +- 使用 `dotnetCampus.TagToVersion` 工具从 Git Tag 自动提取版本号 |
| 69 | +- 版本号格式:`v{major}.{minor}.{patch}[-{prerelease}]` |
| 70 | +- 预发布版本自动识别:`alpha`、`beta`、`rc` |
| 71 | + |
| 72 | +### 构建产物策略 |
| 73 | +- 使用 AOT 编译 (`-p:PublishAot=true`) 提高性能 |
| 74 | +- 生成 self-contained 单文件可执行程序 |
| 75 | +- 平台特定命名: |
| 76 | + - Windows: `DotNetCampus.Terminal-win-x64.exe` |
| 77 | + - Linux: `DotNetCampus.Terminal-linux-x64` |
| 78 | + - macOS: `DotNetCampus.Terminal-osx-x64` |
| 79 | + |
| 80 | +## ⚠️ 踩坑经验 |
| 81 | + |
| 82 | +### 1. 跨平台路径问题 |
| 83 | +**问题**: Windows 使用反斜杠 `\`,Unix 系统使用正斜杠 `/` |
| 84 | +**解决方案**: |
| 85 | +- 使用条件执行分别处理不同平台 |
| 86 | +- 在 matrix 中定义 `path-separator` 变量 |
| 87 | + |
| 88 | +### 2. 文件重命名问题 |
| 89 | +**问题**: 不同平台的文件重命名命令不同 |
| 90 | +**解决方案**: |
| 91 | +```yaml |
| 92 | +# Windows (PowerShell) |
| 93 | +- name: Rename executable (Windows) |
| 94 | + if: matrix.os == 'windows-latest' |
| 95 | + run: | |
| 96 | + if (Test-Path ".\publish\${{ matrix.runtime }}\DotNetCampus.Terminal.exe") { |
| 97 | + Rename-Item ".\publish\${{ matrix.runtime }}\DotNetCampus.Terminal.exe" "${{ matrix.artifact-name }}" |
| 98 | + } |
| 99 | + shell: pwsh |
| 100 | +
|
| 101 | +# Unix (Bash) |
| 102 | +- name: Rename executable (Unix) |
| 103 | + if: matrix.os != 'windows-latest' |
| 104 | + run: | |
| 105 | + if [ -f "./publish/${{ matrix.runtime }}/DotNetCampus.Terminal" ]; then |
| 106 | + mv "./publish/${{ matrix.runtime }}/DotNetCampus.Terminal" "./publish/${{ matrix.runtime }}/${{ matrix.artifact-name }}" |
| 107 | + fi |
| 108 | +``` |
| 109 | + |
| 110 | +### 3. Artifacts 上传路径问题 |
| 111 | +**问题**: 需要同时支持 Windows 和 Unix 路径格式 |
| 112 | +**解决方案**: 在 `upload-artifact` 中同时指定两种路径格式 |
| 113 | + |
| 114 | +### 4. 代码格式检查的团队协作问题 ⭐ |
| 115 | +**问题**: 团队对 .editorconfig 标准尚未统一,强制格式检查可能导致CI失败 |
| 116 | +**解决方案**: |
| 117 | +- 暂时移除 .editorconfig 文件和相关的格式检查步骤 |
| 118 | +- 等待团队统一标准后再重新引入 |
| 119 | +- 保留 CodeQL 和依赖项检查等核心安全功能 |
| 120 | + |
| 121 | +**经验教训**: 在多人协作项目中,代码格式标准化需要全团队讨论决定,不能单方面强制实施 |
| 122 | + |
| 123 | +## 📋 待实现功能 |
| 124 | + |
| 125 | +### 高级特性 (未来考虑) |
| 126 | +- [ ] 增量构建优化 |
| 127 | +- [ ] 性能基准测试自动化 |
| 128 | +- [ ] 自动化变更日志生成 |
| 129 | +- [ ] 代码签名 (Windows 平台) |
| 130 | +- [ ] 集成测试和 UI 自动化测试 (由其他 AI 负责) |
| 131 | + |
| 132 | +## 🤝 与其他角色的协作 |
| 133 | + |
| 134 | +- **测试工程师**: 将来需要集成自动化测试到 CI 流水线 |
| 135 | +- **文档维护员**: 协作维护 CHANGELOG.md 和发布文档 |
| 136 | +- **所有开发AI**: 确保代码质量检查通过 |
| 137 | + |
| 138 | +## 📞 需要人类协助的事项 |
| 139 | + |
| 140 | +以下事项需要项目管理员在 GitHub 上配置: |
| 141 | + |
| 142 | +1. **GitHub Secrets 配置**: |
| 143 | + - 确保 `GITHUB_TOKEN` 具有 Release 创建权限 |
| 144 | + - 如需代码签名,需要配置相关证书 secrets |
| 145 | + |
| 146 | +2. **Branch Protection Rules**: |
| 147 | + - 设置 main 分支保护规则 |
| 148 | + - 要求 CI 检查通过才能合并 |
| 149 | + |
| 150 | +3. **GitHub Actions 权限**: |
| 151 | + - 确保 Actions 有权限创建 Releases |
| 152 | + - 确保 Actions 有权限执行 CodeQL 扫描 |
| 153 | + |
| 154 | +4. **项目设置**: |
| 155 | + - 启用 Vulnerability alerts |
| 156 | + - 启用 Dependency graph |
| 157 | + - 配置 Security advisories |
| 158 | + |
| 159 | +## 💡 持续改进建议 |
| 160 | + |
| 161 | +1. **监控和告警**: 考虑集成构建失败通知 |
| 162 | +2. **缓存优化**: 添加 NuGet 包缓存以加速构建 |
| 163 | +3. **并行化**: 进一步优化构建并行度 |
| 164 | +4. **环境隔离**: 考虑使用容器化构建环境 |
| 165 | + |
| 166 | +--- |
| 167 | + |
| 168 | +**最后更新**: 2025年7月10日 |
| 169 | +**负责AI**: DevOps 自动化专家 |
0 commit comments