我正在使用codeDeploy插件，通过AWS codeDeploy将我的代码直接从bitbucket Git存储库部署到我的EC2实例。然而，过了一段时间，我的codeDeploy控制台中存储了许多修订版，这些修订版存储在一个S3桶中。那么，我应该做些什么来保存S3存储，避免保留旧的codeDeploy版本呢?
是否有可能在成功部署后自动删除这些修订?
如果有X次修改成功，是否可以自动删除?例如，如果我们有三个成功的新版本，则删除旧版本。
CodeDeploy保留来自BitBucket的每个版本，因为服务一直需要上次成功的版本，以实现自动回滚等不同类型的功能。因此，在进行部署时，我们现在不能轻易地覆盖以前的版本。但是对于比上次成功修订更早的所有修订，它们可以被删除。
不幸的是，CodeDeploy目前没有一个好的/优雅的方法来处理这些过时的修订。当bitbucket推送到S3时，如果有一个覆盖选项就好了。
CodeDeploy是一个纯粹的部署工具，它不能处理S3桶中的修订。
我建议您研究S3的"生命周期管理"。由于您使用的是版本控制桶(我假设)，因此总是有一个最新版本和0到许多过时版本。你可以设置一个"NoncurrentVersionExpiration"类型的生命周期配置，这样过时的版本将在几天后被删除。
这种方法仍然无法维持固定数量的部署，因为AWS只允许指定以天为单位的生命周期。但它可能是您的用例的最佳替代方案。
[1] http://docs.aws.amazon.com/AmazonS3/latest/dev/how-to-set-lifecycle-configuration-intro.html[2] http://docs.aws.amazon.com/AmazonS3/latest/dev/intro-lifecycle-rules.html
CodeDeploy不处理类似Jenkins示例的特性:"保持最后X[成功与否]运行"。但是，对于S3 Lifecycle，您可以在3个月后自动过期(删除)S3对象。
一方面，这个解决方案是一个很好的FinOps操作，当在过期窗口(至少3个部署)有一个恒定的活动时，通过确保CodeDeploy的自动回滚过程并降低S3成本。
另一方面，当您有尖锐的活动时，或者在指定的S3过期延迟期间根本没有部署时，此解决方案的效率较低:在上一次部署后12个月的情况下，当此部署失败时，Code Deploy将无法继续回滚，因为以前的工件在S3中不再可用。
作为缓解措施，我建议您使用智能分层，它可以在不影响CodeDeploy功能的情况下将S3成本划分为4。您也可以设置有效期为12个月，以删除古代文物。
最后一个解决方案是编写一个由每周Cloudwatch Events安排的Lambda，这将:
- 使用自己的标准列出部署成功/失败状态
- 获取每个 的部署详细信息
- 使用条件(日期，用户，…)再次过滤掉此部署
- 使用部署详细信息删除S3对象