代码之家 › 专栏 › 技术社区 › systemdebt

企业级CI/CD管道的范围

aws-codepipeline continuous-deployment continuous-integration amazon-web-services

systemdebt · 技术社区 · 5 年前

我正在写下使用AWS原生工具开发的CI/CD管道的范围。你推荐什么? 讨论我正在最终确定我们的CI/CD管道的范围,该管道将使用AWS本机工具Codepipeline、code build等。基本管道样板文件是用CDK编写的,到目前为止,我们喜欢这个选择。现在,我们想定义它的最终范围,以下是我们迄今为止得到的。

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

每个分支的管道

一次构建,多次部署

跨帐户部署,即从工具帐户部署到不同环境(开发/质量保证/产品)

基于分支名称的管道行为

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

集成静态代码分析

部署前由多人手动批准

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

确定AWS云形成安全测试(可能通过SecurityHub)

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

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

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

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

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

支持预览部署阶段

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

1 回复 | 直到 5 年前

Rodrigo Murillo 5 年前

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

我会添加一个AMI构建阶段,使用Packer构建特定于应用程序的AMI。看见
https://github.com/awslabs/ami-builder-packer 这是一个很好的参考架构。

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

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

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

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

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

还要考虑在管道中使用代码构建完整的基础结构,如果使用TrRAFrm或CyrdFeCube。知道你可以从头开始构建一切是一个很好的基础。使用AWS组织,您甚至可以从头开始创建新的AWS帐户,并在新帐户中构建您的整个基础设施。

Docker图像安全扫描是与集装箱安全相关的另一个重要管道阶段。可以根据CVE和其他漏洞列表扫描图像。看见 https://docs.docker.com/engine/scan/

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