拉取请求中的云成本估计

开发团队使用拉请求作为其工作流的关键部分。拉请求用于各种事情，比如在合并之前进行linting和运行测试，以避免破坏更改。GitHub动作提供了一种使Pull请求做更多事情的简单方法，而GitHub Marketplace有数千个动作可以快速、轻松地插入到工作流中。集成到Pull请求中的工具的伟大之处在于，通常只需要团队中的一个人来添加它，每个人都会自动从它中受益，并将其作为工作流的一部分。

团队也经常使用拉请求来检查和讨论更改。Terraform和Pulumi等基础设施即代码工具的日益流行意味着也可以通过拉请求来驱动部署。这使开发人员、DevOps/SRE、架构师和管理人员能够讨论正在审查的代码更改可能存在的安全、性能和成本方面的具体问题。

我们已经看到许多组织使用来自云提供商和第三方供应商的展示和按存储容量使用计费报告来帮助团队负责其云成本并对其进行优化。之所以需要这些云成本管理工具，首先是因为云定价很复杂；例如，AWS有数百项服务，这些服务的价格高达数十万。虽然现有的云成本管理工具有一定的用途，但它们中的大多数都提供了“事后”的视图，因此它们无法帮助做出开发过程中需要做出的决策。例如，作为一名开发人员，我想快速了解如果将EBS卷的IOPS从100更改为200将花费多少。我知道我可以使用AWS网站上的信息来计算这一点，但如果作为拉取请求的一部分，我要更改多个内容，这可能会花费比我希望的更长的时间。此外，如果我可以与团队其他成员和我的经理讨论成本变化，看看他们的想法，那就太好了；就像我可以处理拉请求中的其他变化一样。

检查是否有任何Terraform文件(.tf)作为Pull请求的一部分进行了更改，如果已更改，则在主分支和Pull请求上运行infracost。

如果有更改，则发布对拉式请求的评论。可以选择设置PERCENT_THRESHOLD；例如，仅当成本估算更改+/-5%时才发布注释。

显示低于成本的输出的不同之处。这显示了导致每月成本估计更改的更改的详细细目。

我们希望开发团队发现这一点很有用，因为它易于设置，并且可以更好地了解基础设施即代码更改带来的成本估算。试一试，让我们知道它在Twitter或GitHub问题上的进展情况。