为什么（或在什么情况下）如此关注构建大小？
注意：我问的原因是因为与过去相比，我认为诸如存储和计算之类的资源相对便宜，因此，如果有的话，我希望构建大小现在不再是问题比过去
#1 楼
当我提出构建大小问题时，它通常不是源于“它太大了，存储起来会很昂贵”。大型构建的主要问题如下-
增加了运输时间。
频繁地对大型工件进行频繁的更改加上较大的保留时间，这使得存储此类工件变得昂贵，而对于像docker镜像这样的分层工件而言，存储成本却降低了。
工件通常很耗时，比创建更小的工件更耗时。使过程自动化以创建较小的工件可能会花费一些时间，但是可重复的自动化过程应尽可能短，以实现快速反馈。
对于较大的工件，从故障中恢复（取决于配置）可能会花费更多的时间，尤其是当需要重新应用较旧的工件而不是有缺陷的较新工件时。
我赞成以下四个devops指标：
更改的最佳时机-缩短部署时间
-部署频率增加-恢复服务的时间-缩短故障发生率
更改故障率-永远降低故障率
大型工件通常会造成问题这些指标中的每一个指标都没有真正与存储成本有关–因为这很便宜，时间也很昂贵。
#2 楼
用更多示例对Evgeny的答案进行补充。构建大小的含义可能会有所影响：
如果它是工件的大小）（每一个都单独构建或合并使用）的大小-如果这些操作有大小限制，并且超出了限制，则在工件存储或使用/部署操作中可能很重要。例如，Google App Engine应用程序具有这样的部署限制，如果达到的部署将失败，请参见部署到Google App Engine时的错误。
如果这是您在其中执行构建的工作空间的大小，则可能与工作空间有关管理的角度。甚至2G都可能是重要的-例如，如果要在没有大量RAM的计算机上构建RAM文件系统。但是某些构建可能更大—我必须处理500G +的工作空间（当我的大多数服务器磁盘都在1T以下时）。
如果构建是CI / CD管道的一部分，则更大的构建构建大小越长，管道执行时间就越长（执行实际构建，并且在可行的情况下，进行归档，部署以进行测试，在发生故障的情况下进行分析，清理等）-总体开发速度越慢/风险越大/成本越高。
如果您遇到硬性限制，则必须要有创造力才能解决（并非总是简单/可能）。如果仅是性能/成本方面的问题，您还可以选择接受和使用它，和/或部分/逐步解决它。
可能值得区分：
膨胀的版本-当不必要地增加大小时-通常可以通过删除不必要的部分来解决问题
情况是真正需要的内容本身-大小无关紧要尽可能多地解决-唯一的解决方法可能是牺牲一些功能
#3 楼
我将添加一个实际遇到的非常具体的问题。这是我们当前正在遭受的不良体系结构的副作用：由于我们的构建很大，并且我们需要加载很多依赖关系，因此简单地将它们放在一起需要很长时间。我们早就应该将构建分为多个小型构建，作为一种微服务体系结构的方法，而不是一个大型整体。
运行整体测试需要大约45分钟，并且阻塞了我们的CI环境暂时。
由于它的负载非常大且需要花费很长时间，因此我们目前无法并行运行多个构建。
我已经从理论上进行了阐述，这应该显示出大型构建通常需要的更多（可能）附带影响。
评论
您需要查看构建的频率，正在构建的不同项目的数量，正在构建的分支的数量以及保留的构建的数量（以允许还原不良版本，或者可能供审核员使用）。将其相乘不仅可以获得磁盘空间，还可以获得网络带宽。例如。 200MB构建* 20个微服务*每天5个构建= 20GB /天。如果您一年中构建200天，则为每年4TB。对于网络和磁盘，开发人员还可以通过WiFi下载它们并将它们存储在小型SSD上。