企业级CI/CD管道的范围

Question

我正在写下我们的CI/CD管道的范围，我们将使用AWS本机工具进行开发。你有什么建议吗？讨论过程中，我正在最后确定我们的CI/CD管道的范围，该管道将使用AWS本机工具Codepipeline、代码构建等等。基本的管道样板是用CDK写的，我们喜欢到目前为止的选择。现在，我们想为它定义最后的范围，下面是我们到目前为止得到的结果。

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

每支管线

构建一次，部署多个

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

基于分支名称的管道行为

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

集成静态代码分析

部署前由多个人员手动批准

从管道中识别应用程序源代码中的安全代码漏洞(可以通过Synk)

识别AWS云形成安全性测试(可能通过SecurityHub)

允许开发人员从CI/CD中在公共沙箱帐户中部署特性分支

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

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

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

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

支持预览部署阶段

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

Answer 1

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

我会添加一个AMI构建阶段，它将使用Packer构建应用程序专用的AMIs。看见

https://github.com/awslabs/ami-builder-packer作为一个良好的参考体系结构。

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

考虑一下语义或常规提交语法，它将启动基于添加到提交消息的人/机器可读的标记的动态构建活动。

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

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

我没有看到它被调用，但是单元测试、功能测试和api测试应该包含在动态应用软件测试中。

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

还可以考虑在管道中从代码构建完整的基础设施，如果您正在使用Terraform或Cloudformation。知道你可以从头开始构建所有东西是一个很好的基线。使用AWS组织，您甚至可以从头创建新的AWS帐户，并在新帐户中构建整个基础设施。

码头图像安全扫描是与集装箱安全相关的另一个重要的管道阶段。可以针对CVE和其他漏洞列表扫描图像。请参阅https://docs.docker.com/engine/scan/

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