现在我对今年报告中的以下数据有疑问（第21页）。
我们可以将2016年和2017年的数据相乘吗？
例如，以变更的交货期为首。实时（例如4320小时）进行错误修复，然后
在2016年花了不到2个小时，而在2017年花了16秒？
经速传送速度现在是真的吗？ 2014年，管理层对甚至30倍的加速率都持怀疑态度。现在我很怀疑。
问题：对于非常轻量级的微服务，这必须是绝对最小值。也就是说，随着bug修复提交的到来。.
从这一刻起，您真的很想起了。 >您的基础设施确实非常快（或者，您可以获得最快）。
对吗？
#1 楼
我不会完全这样计算。这不一定意味着变更集的实际验证时间会减少那么多。验证过程本身可以（并且通常是现在）是一个处理管道，其中平均/有效验证实际上，每个变更集的时间可以减少到非常少的数量。
例如，处理管道可以同时处理多个变更集。假设您有60个建议的更改，每个更改涉及存储库中的不同文件，则可以将它们组合成等效的单个uber-changeset，涉及60个文件。然后，您可以通过一个耗时1h的验证步骤来处理该超级更改集。如果验证通过，则即使实际验证时间为1h，您也会获得x60的加速因子和每个变更集的有效验证时间1分钟。当然，当验证失败时，您将失去一些加速，您需要进行二等分以识别错误的变更集，但这是另一回事。
或者您可以验证每个变更集通过并行执行的60个1h验证独立进行。有效验证时间相同，但验证资源使用量要高得多。
我想指出的是，有一些方法可以构建处理管道，从而可以大大减少有效的每变更集验证时间，并且仍然保持大型项目的敏捷性。
要考虑的另一点是分支策略。这六个月不是实际的验证时间。大部分时间都只是花在浏览分支Spagetti上和与集成地狱作斗争，只是将修补程序传播到正确的运输分支中-瀑布开发模型的效果在当时被认为是正常的。
如今，CI / CD（合适的替代品，而不是CI剧院）和基于中继的开发消除了所有浪费的时间/精力和偏颇的步骤，并且从集成到中继中起就几乎可以立即交付此修复程序-否不可预测的大规模分支合并障碍永远存在于运输之前。