企业级 CI/CD 管道的范围
Scope for an enterprise grade CI/CD pipeline
我正在写下要使用 AWS 本机工具开发的 CI/CD 管道的范围。您有什么推荐的吗？
讨论
我正在最终确定将使用 AWS 原生工具 Codepipeline、代码构建等的 CI/CD 管道的范围。基本的管道样板是用 CDK 编写的，到目前为止我们喜欢这个选择。现在，我们想为它定义最终范围，这是我们目前所获得的。
我很想知道 tools/abilities 集成到您的 CI/CD 管道中以确保我们正在考虑开发企业级 CI/CD 管道。
每个分支管道
构建一次，部署多次
跨账户部署，即从工具账户部署到不同环境 (dev/QA/prod)
基于分支名称的管道行为
测试执行基于stage/environment
集成静态代码分析
部署前多人手动审批
从管道中识别应用程序源代码中的安全代码漏洞（可能通过 Synk）
识别 AWS 云形成安全测试（可能通过 SecurityHub）
允许开发人员从 CI/CD
的公共沙箱帐户中部署功能分支
通过将事件从管道发送到云端 -watch
为 builds/deployments 创建仪表板
在测试失败时观察警报，以便在这种情况下发生自动回滚
当配置规则失败时观察警报，以便在这种情况下发生自动回滚
基于事件的每个分支的动态管道
支持预览部署阶段
我很想听听当前范围improved/added可以做什么
这是一个非常完整的范围，干得好。
我会添加一个 AMI 构建阶段，它将使用 Packer 构建特定于应用程序的 AMI。参见
https://github.com/awslabs/ami-builder-packer 一个好的参考架构。
我还会考虑动态操作仪表板，它会根据项目中使用的 key/updated 资源生成更新的 CloudWatch 仪表板。
考虑语义或常规提交语法之类的东西，这将根据添加到提交消息中的 human/machine 可读标签启动动态构建活动
Semantic Commits are commit messages with human and machine readable meaning, which follow particular conventions
例如，如果您使用字符串 build/preview 推送提交消息，构建管道将按需启动预览部署。它可以获取 pr 编号并为应用程序创建一个动态 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/
我想添加一个 documentation/report 发布阶段，它获取项目资产并将它们集成到在线文档系统中。
例如，您可以使用 Antora/AsciiDoctor/Netlfy 构建文档工具链，在构建时直接从项目存储库为所有项目文档生成 HTML、pdf 和 Docx 文件。参见 https://fedoramagazine.org/using-antora-for-your-open-source-documentation/
我正在写下要使用 AWS 本机工具开发的 CI/CD 管道的范围。您有什么推荐的吗？ 讨论 我正在最终确定将使用 AWS 原生工具 Codepipeline、代码构建等的 CI/CD 管道的范围。基本的管道样板是用 CDK 编写的，到目前为止我们喜欢这个选择。现在，我们想为它定义最终范围，这是我们目前所获得的。
我很想知道 tools/abilities 集成到您的 CI/CD 管道中以确保我们正在考虑开发企业级 CI/CD 管道。
每个分支管道
构建一次，部署多次
跨账户部署，即从工具账户部署到不同环境 (dev/QA/prod)
基于分支名称的管道行为
测试执行基于stage/environment
集成静态代码分析
部署前多人手动审批
从管道中识别应用程序源代码中的安全代码漏洞（可能通过 Synk）
识别 AWS 云形成安全测试（可能通过 SecurityHub）
允许开发人员从 CI/CD
的公共沙箱帐户中部署功能分支通过将事件从管道发送到云端 -watch
为 builds/deployments 创建仪表板在测试失败时观察警报，以便在这种情况下发生自动回滚
当配置规则失败时观察警报，以便在这种情况下发生自动回滚
基于事件的每个分支的动态管道
支持预览部署阶段
我很想听听当前范围improved/added可以做什么
这是一个非常完整的范围，干得好。
我会添加一个 AMI 构建阶段，它将使用 Packer 构建特定于应用程序的 AMI。参见
https://github.com/awslabs/ami-builder-packer 一个好的参考架构。
我还会考虑动态操作仪表板，它会根据项目中使用的 key/updated 资源生成更新的 CloudWatch 仪表板。
考虑语义或常规提交语法之类的东西，这将根据添加到提交消息中的 human/machine 可读标签启动动态构建活动
Semantic Commits are commit messages with human and machine readable meaning, which follow particular conventions
例如，如果您使用字符串 build/preview 推送提交消息，构建管道将按需启动预览部署。它可以获取 pr 编号并为应用程序创建一个动态 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/
我想添加一个 documentation/report 发布阶段，它获取项目资产并将它们集成到在线文档系统中。 例如，您可以使用 Antora/AsciiDoctor/Netlfy 构建文档工具链，在构建时直接从项目存储库为所有项目文档生成 HTML、pdf 和 Docx 文件。参见 https://fedoramagazine.org/using-antora-for-your-open-source-documentation/