持续集成和持续部署/交付（CI/CD）是自动化构建、测试和部署管道的实践。以下是在生产团队中实际有效的方法。
持续集成：它实际上意味着什么
CI不仅仅是”我们有一个管道”——它意味着开发者频繁地将代码合并到共享分支（至少每天一次），合并触发自动构建和测试套件，团队将保持构建通过作为首要优先级。原始CI纪律（Martin Fowler，2000年代）：开发者每天至少提交一次到主线（主干）；长期功能分支与真正的CI不兼容；管道必须足够快地完成，以便不减慢开发周期（理想情况下不超过10分钟）。大多数团队的实际状态：大多数团队将他们的设置称为”CI”，但使用长期功能分支（几周或几个月）并仅在分支上运行测试——这不是原始意义上的CI，但这是行业规范。在实践中重要的是：管道必须在缺陷到达主分支之前捕获它们；每个开发者在合并之前必须看到构建结果；损坏的构建必须在几分钟内修复，而不是几小时。管道解剖：代码检查和静态分析（快速，捕获明显问题）；单元测试（快速，隔离）；集成测试（较慢，测试模块边界）；端到端测试（慢速，测试完整堆栈——运行频率较低或仅在主分支上）。无情地并行化：并行运行独立的测试套件。可以在2分钟内并行完成的10分钟管道是日常开发者税。
持续部署vs持续交付
持续交付：每个通过管道的提交都有潜在的可部署性——但部署到生产是一个故意的人类行为。持续部署：每个通过管道的提交都会自动部署到生产。哪个适合你的团队：CD适用于快速回滚可行且生产Bug成本可恢复的Web应用程序。没有自动部署的持续交付适用于：你有发布窗口时（金融系统、受监管行业）；部署需要跨多个团队协调；或者你对测试覆盖率还没有足够信心自动部署时。部署本身：蓝绿部署（两个相同的生产环境，流量在它们之间切换——零停机部署，通过切换回去轻松回滚）；金丝雀部署（新版本部署到一小部分流量，随着信心增长逐渐增加）；功能标志（将部署与功能发布解耦——代码部署到所有用户，但功能被选择性激活）。回滚策略：基于错误率峰值的自动回滚；功能标志关闭作为软回滚；数据库迁移可逆性是回滚中最难的部分（在部署代码更改之前以向后兼容的方式部署模式更改）。
是什么使管道良好
速度：管道必须足够快，以便开发者不会放弃它。超过20分钟，管道速度成为生产力瓶颈。积极缓存——node_modules、Maven/Gradle依赖项、Docker层。可靠性：不稳定的测试比没有测试更糟糕——它燃烧开发者的信任并被忽视。立即修复或删除不稳定的测试。零容忍间歇性失败。反馈质量：失败的管道应该告诉开发者确切什么破了以及为什么。日志链接是不够的；CI系统应该突出显示第一个失败。秘密管理：永远不要在存储库的环境变量中存储秘密；使用CI平台的秘密管理（GitHub Actions秘密、Vault、AWS Secrets Manager）；按计划轮换凭据。分支保护：在合并到主分支之前要求通过管道；要求至少一名代码审查者；防止对主分支强制推送。管道中的基础设施即代码：CI/CD管道定义本身（GitHub Actions YAML、Jenkinsfile、.gitlab-ci.yml）应该被审查、版本控制，并被视为一等代码。绕过审查的管道更改是安全风险。
