从6个月到16秒？从多拉和傀儡实验室的DevOps报告中提取DevOps加速数据
傀儡实验室的年度DevOps报告是一个非常好的和代表性的信息来源，AFAIK。事实上，有了金·吉恩，他们才是我认为的工业大师。
现在，我对今年的报告中的以下数据提出了一个问题(第21页)。
我们能把2016年和2017年的数据乘以吗？
例如，为更改留出准备时间。
2555x440=1124000 # more than a milion times faster?这是否意味着，如果2015年需要6个月(比如180天的实时时间，即4320小时)才能完成故障修复，那么
- 2016年花了不到2个小时，
- 2017年是16秒吗？
现在的经纱速度是真的吗？2014年，管理层甚至对30倍的提速都持怀疑态度。现在我开始怀疑了。
问:对于非常轻量级的微服务，这必须是绝对最小值。也就是说，当错误修正提交到..。
- 从这一刻起你真的算了
- 您没有编译步骤。
- 码头工人的形象很小
- 你有非常快(或最快)的基础设施。
对吗？
回答 1
DevOps用户
发布于 2017-11-23 17:16:42
我不会那样计算的。这并不一定意味着更改集的实际验证时间会减少那么多。
核查过程本身可以是(而且现在经常是)一条处理管道，在这条管道中，每个变化集中的平均/有效验证时间实际上可以减少到疯狂的小数量。
例如，处理管道可以同时处理多个变更集。如果您已经，比方说，有60个提议的更改，每个更改都接触到存储库中的不同文件，则可以将它们组合成一个等效的单个uber-changeset来处理60个文件。然后，您可以通过一个验证步骤来处理这个uber变更集，这个步骤需要，比方说，1小时。如果验证通过，则获得x60的加速比因子和每改变1分钟的有效验证时间，即使实际验证时间为1h。当然，当验证失败时，您将失去一些加速，您需要执行二分法来识别错误的变更集，但这是另一回事。
或者，您可以通过60小时的并行验证，对每个变更集进行独立验证。相同的有效验证时间，但具有更高的验证资源使用。
关键是，我想，有一些方法可以构建处理管道，这可以大大减少有效的每次更改集验证时间，并且仍然保持非常大规模的项目的灵活性。
另一点需要考虑的是分支策略。那6个月并不是真正的核实时间。大部分时间只是通过枝条空间导航和与整合地狱战斗，仅仅是为了将补丁传播到正确的航运分支--瀑布开发模型的效果，这在当时被认为是规范的。
今天CI/CD (适当的，而不是CI剧院)和基于主干的开发消除了所有浪费的时间/精力和边步，修复几乎已经准备好交付从一开始，它集成在主干-没有不可预测的大规模分支合并障碍站在航运之前。
https://devops.stackexchange.com/questions/2635
复制相似问题
腾讯云开发者
