企业级CI/CD管道的范围
我正在写下我们的CI/CD管道的范围，我们将使用AWS本机工具进行开发。你有什么建议吗？讨论过程中，我正在最后确定我们的CI/CD管道的范围，该管道将使用AWS本机工具Codepipeline、代码构建等等。基本的管道样板是用CDK写的，我们喜欢到目前为止的选择。现在，我们想为它定义最后的范围，下面是我们到目前为止得到的结果。
我想知道哪些工具/能力集成到您的CI/CD管道中，以确保我们正在考虑开发企业级CI/CD管道。
每支管线
构建一次，部署多个
跨帐户部署，即从工具帐户部署到不同环境(dev/QA/prod)
基于分支名称的管道行为
基于阶段/环境的测试执行
集成静态代码分析
部署前由多个人员手动批准
从管道中识别应用程序源代码中的安全代码漏洞(可以通过Synk)
识别AWS云形成安全性测试(可能通过SecurityHub)
允许开发人员从CI/CD中在公共沙箱帐户中部署特性分支
通过将事件从管道发送到云-watch，为构建/部署创建仪表板
在测试失败时观察警报，以便在这种情况下自动回滚。
在配置规则失败时观察警报，以便在这种情况下自动回滚。
基于事件的每个分支的动态管道
支持预览部署阶段
我很想听听在当前范围内可以改进/增加什么。
回答 1
Stack Overflow用户
发布于 2020-12-04 18:11:37
这是一个非常完整的范围，很好的工作。
我会添加一个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/
https://stackoverflow.com/questions/65152987
复制
腾讯云开发者
