我们正朝着将庞大的代码管道分离为较小的代码管道的方向发展。但是在此之前，我需要一些与此相关的反馈。
目前，我们为其中一个项目部署了一个代码管道：
- 网络堆栈（VPC，子网等）
- 资源堆栈（RDS，Redis，DynamoDB，S3存储桶）
- Firehose-With-Transformation-Lambda-Stack（使用转换lambda设置firehose，将数据存储在S3中）
- Lambda堆栈（特定于项目的业务逻辑）
- API网关堆栈（端点，api密钥，基本路径映射）
- 监视堆栈（从先前堆栈的所有资源中获取指标，然后显示一个仪表板）
代码管道由代码提交触发，因此每当我们推送代码更改时，管道都会被触发。
现在，有两个主要原因使我们想分开上面的管道。
- lambda的微小变化需要很长时间才能完成
代码管道。 ->快速解决方案直接从更新lambda
在make文件中直接直接更新lambda，但这就是更多
骇客。
- 多个项目正在使用网络等资源以及RDS和DynamoDB等数据库
有自己的小型基础架构。
- 安排更多和更少的代码管道将使我们能够进行关注点分离，而不必再次进行关注，
同样，当在
基础架构中的其他堆栈。
基于以上信息，我有几个问题：
- 该方法的优缺点是什么？
- 当父代码行结束时，如何执行一个代码管道的触发？ （是否要使用CW事件？）-万一需要
父堆栈中发生了更改（在不同的代码管道中）
其中涉及到资源的替换，因此涉及价值的替换
需要传播到子堆栈（以不同的方式
代码管道）
更多信息：
在研究期间-这就是我发现的。可以基于CodePipeline状态更改触发的Cloudwatch事件规则-https://docs.aws.amazon.com/codepipeline/latest/userguide/detect-state-changes-cloudwatch-events.html
此外，AWS解决方案架构师指出，我可以将Step函数用于CodePipeline同步，但是对于不同的CodePipelines，我需要多个启动状态。