企业级 CI/CD 管道的范围

Question

我正在写下使用 AWS 原生工具开发的 CI/CD 管道的范围。你有什么建议吗？ 讨论 我正在最终确定我们的 CI/CD 管道的范围，该管道将使用 AWS 原生工具 Codepipeline、代码构建等。基本的管道样板是用 CDK 编写的，到目前为止我们喜欢这个选择。现在，我们要定义它的最终作用域，这就是我们目前所得到的。

我很想知道您的 CI/CD 管道中集成了哪些工具/功能，以确保我们正在考虑开发企业级 CI/CD 管道。

每个分支的管道

一次构建，多次部署

跨账户部署，即从工具账户部署到不同的环境 (dev/QA/prod)

基于分支名称的管道行为

基于阶段/环境的测试执行

集成静态代码分析

部署前由多人手动批准

从管道中识别应用程序源代码中的安全代码漏洞（可能通过 Synk）

识别 AWS 云形成安全测试（可能通过 SecurityHub）

允许开发人员在 CI/CD 的公共沙箱帐户中部署功能分支

通过将事件从管道发送到云 -watch 来为构建/部署创建仪表板

在测试失败时观察警报，以便在这种情况下自动回滚

在配置规则失败时观察警报，以便在这种情况下自动回滚

基于事件的每个分支的动态管道

支持预览部署阶段

我很想听听在当前范围内可以改进/添加什么

Answer 1

这是一个非常完整的范围，很好的工作。

我将添加一个 AMI 构建阶段，该阶段将使用 Packer 构建特定于应用程序的 AMI。请参阅
https://github.com/awslabs/ami-builder-packer 了解良好的参考架构。

我还会考虑动态操作仪表板，它会根据项目中使用的关键/更新资源生成更新的 CloudWatch 仪表板。

考虑语义或常规提交语法之类的东西，它会根据添加到提交消息中的人机/机器可读标签来启动动态构建活动

语义提交是具有人类和机器可读含义的提交消息，它们遵循特定的约定

例如，如果您推送带有字符串 build/preview 的提交消息，则构建管道将按需启动预览部署。它可以获取 pr 编号并为应用程序创建一个动态 url，该 url 可能会一直持续到分支合并。 https://nitayneeman.com/posts/understanding-semantic-commit-messages-using-git-and-angular/ 那里有一些想法。

没看到叫出来，但是动态应用软件测试应该包括单元测试、功能测试、api测试。

可以对已完成的部署执行负载测试和漏洞测试，以确保每个构建都符合既定的性能或安全标准。

如果您使用的是 Terraform 或 Cloudformation，还应考虑在您的管道中从代码构建完整的基础架构。知道您可以从头开始构建所有内容是一个很好的基准。使用 AWS Organizations，您甚至可以从头开始创建新的 AWS 账户，并在新账户中构建您的整个基础设施。

Docker 镜像安全扫描是与容器安全相关的另一个重要管道阶段。可以针对 CVE 和其他漏洞列表扫描图像。见https://docs.docker.com/engine/scan/

我喜欢添加一个文档/报告发布阶段，该阶段将项目资产整合到在线文档系统中。 例如，您可以使用 Antora/AsciiDoctor/Netlfy 构建一个文档工具链，该工具链将在构建时直接从项目存储库中为所有项目文档生成 HTML、pdf 和 Docx 文件。见https://fedoramagazine.org/using-antora-for-your-open-source-documentation/