无服务器——CI/CD 系统应该是短暂的和无服务器的。没必要管理 Jenkins 或单个节点。管理 CI/CD 机器使得引入配置和环境漂移变得非常容易，这会导致难以追踪错误。 Container-native 通常是一个不错的选择，尤其是当您经常在容器内部署软件时，但任何提供真实临时环境的东西都是好的。
本地（云端）——对于小型项目，使用托管 CI/CD 服务很好，但对于任何比玩具项目更大的项目，您可能应该在自己的云帐户中启动 CI/CD 运行器。
最小权限/本机 IAM – 工作人员应以云原生方式（例如 OIDC）进行身份验证，并使用最小权限集进行部署。虽然在项目部署更多种类和数量的服务时扩大工作人员的范围似乎很麻烦，但限制爆炸半径和隔离环境将使您避免出现各种错误和错误。
易于调试——易于调试意味着可以在本地以有意义的方式运行管道。这也意味着可以从运行中轻松访问日志和工件。
触发器，但并不复杂——GitHub Actions 提供了一个很好的模型来自动运行工作流（来自拉取请求或合并事件）以及手动触发器。但是，不要围绕手动触发器构建复杂的业务流程。
代码，而不是 YAML——Code for Infrastructure ，我相信用完整的编程语言而不是配置语言来设计管道要容易得多。您可以获得可重用性、控制流、强类型以及描述依赖关系图时可能需要的其他属性。
DAG——已经有一些关于拥有完全事件驱动的 CI/CD 系统的实验。一般来说，我认为最好有一个编码依赖图的静态 DAG。事件可能会触发初始工作流，并可能在 DAG 竞争（或失败）时发出，但不会在两者之间触发。
更进一步交流可以SX加入我的知识星球获取更多资料和云原生技术书籍。
