埃森哲( Accenture )正在大量谈论他们的“多速IT”方法。
从他们的战略咨询中可以看出:
在他们的DevOps博客上的博客文章:
以及在许多其他地方处理技术组织的各个方面。
他们自己的“DevOps负责人”正在谈论多速如何是一种糟糕的实践https://www.youtube.com/watch?v=yGcXLwsnDgg。
这种“多速度IT”的理念是否有其优点,并可用于与DevOps保持一致的持续改进?还是它违背了一些常见的DevOps实践?
发布于 2018-08-09 16:39:25
环境的不同部分可能以不同的频率发生变化,这是有原因的。一个例子可能是日历服务,大多数大型组织都有日历服务,如果是假日,则提供有关当前日的信息。日历服务不需要频繁更改,因为它提供了稳定的功能。这种日历服务可能被许多不同类型的应用程序使用,它们也以不同的速度运行。
存在多个速度,因为您需要处理交付价值的更改。许多人指出,多速度是为了处理字型终端系统和记录系统。是的,通常情况下,面向用户的系统变化更频繁,因为希望为最终用户进行更新,并尝试不同的表示数据的方法,以获得最佳价值。然而,为了满足新的业务需求,可能需要快速更改记录系统。
如果应用程序的所有部分都是使用具有适当自动化测试和部署的管道构建的,它们是独立测试的方式,也是一起测试的方式,那么任何部分都可以根据需要移动。它类似于齿轮,认为不同的部分移动,但需要集成,使他们,你知道,他们一起工作,因为他们被部署。
发布于 2017-10-20 13:07:34
基于此
较小的齿轮比较大的齿轮移动得快得多,但在两个齿轮联锁的地方,它们保持对齐以不停止运动。
这句话
多速IT的整体理念是降低功能交付的相互依赖性。另一方面,您需要花费更多的精力,使正确的实践和工具到位,以支持这一点。例如,您希望确保您可以使用自动化测试快速测试不同的接口版本,您需要有良好的版本控制,以确保为每个应用程序准备了正确的组件,您还希望确保您可以通过抽象和必要的分支来很好地管理代码线。配置管理、打包和部署的基础知识将变得更加重要,因为您希望减少您必须在您的环境中处理的变量数量。通过使这些过程完全自动化,您最好删除通过手动步骤引入的那些变量。
从这个职位中可以说,多速度IT方法可以与DevOps保持一致,因为它知道一个组织中有多个部门和过程,只要这些部门和流程变得不那么依赖,就不需要在速度上对齐。例如,只要组件是版本化的、向后兼容的和文档化的,多个DevOps团队就可以在不相互阻碍的情况下创建不同数量的特性。
https://devops.stackexchange.com/questions/1411
复制相似问题