本帖最后由 monicazhang 于 2017-8-22 16:11 编辑
“ 技 术 实 践
”
今天，DevOps已经被视作更快交付软件，获得更好的效率以及取得竞争优势的重要途径。而一些更加急切的用户则开始研究他们应该买什么样的工具，其实，更加重要的是这些技术上的实践，而这些实践才包涵着转向DevOps的初心所在。
而关于这些更为细致和共通的项目，研究也一直在继续： 版本控制实践 持续集成 基于Trunk的开发 自动化
而今年，增加了对技术架构和团队的结构的关注，同样会研究它们是如何影响组织开发和交付软件的能力。
“ 持 续 交 付
”
去年，研究发现组成持续交付的实践：开发自动化，自动化测试，持续集成，基于Trunk的开发，所有构件的版本管理，这些对部署之痛，IT绩效以及变更失败率起到重要的作用。自然，最终会直接影响生产性/市场份额/利润等重要组织目标。
去年，研究使用上述实践组成了持续交付的模型。而今年的研究则使用了其产生的结果作为模型，在这个模型中，将会根据团队获取如下两项产出的能力对持续交付进行衡量：
全生命期的按需部署： 团队能够在软件的全生命交付周期对产品或者最终的用户按需进行部署。 快速反馈回路： 团队的每一个成员都参与到对质量和系统的部署能力的快速反馈中，而对这些反馈所必须的应对则是最高的优先顺位。
而这些可以使得我们做两件很有意思的事情。第一，我们能够看出实现这些产出能够对IT绩效和部署之痛所带来的影响。其次，我们能看到哪些要素最为影响这些产出，同时也能够研究一下诸如松耦合架构等所能带来的影响。
持续交付 的5项 “ 影 响 要 素
”
我们希望知道持续交付受那些影响要素的程度，研究发现如下五项要素都正面影响持续交付： 综合版本控制 持续集成和基于Trunk的开发 安全与软件交付的融合 测试自动化 部署自动化
在所有的要素之中，自动化测试则是最大贡献者。
另外，良好的架构对持续交付的影响也是今年重要的确认点之一，研究的结果也证实了架构对于实现高绩效的重要性。
“
架 构
”
在过去的几年中，对架构与持续交付/IT绩效的关联已经做过了调查。而今年则进行了更深入的分析研究，发现创建松耦合的架构和团队对于驱动持续交付实践的能力有非常明显的作用。
通过如下两个方面来对服务和组件之间的耦合度进行判断： 可否做测试而不需要额外的集成环境 对象应用可否独立地部署或者发布而不必考虑其他的应用或服务 对于那些商用关联的COTS场景，对象环境中也确认了是否包涵COTS。
在2015年的调查报告中，就曾经发现高绩效团队的耦合度明显低于中低绩效团队。而这些对于应用程序的影响也是一样的。而今年，如下两项假定希望在研究中进行验证： 给予了更多权利，能够自主选择工具和实现的团队表现更好 松耦合的良好封装的架构能够驱动IT绩效
关于第一项假定，通过研究发现，相比较于强制地集中控制式的工具使用，能够自主选择工具的团队确实表现更佳。没有人比团队成员自身更清楚地了解什么样的工具能给他们带来更高的效率，给予团队自主选择的权利能够带来更好结果自然毫无意外。
第二项假定同样在研究中得到了印证。那些在IT和组织绩效上表现强劲的团队，大都使用了松耦合的系统架构，这样使得交付团队能够独立地进行测试/发布/系统变更而不必考虑和其他团队的额外工作/资源协调/审批等待/反复交流等，架构和团队的松耦合带来了确确实实的好处。
就像康威定律所描述的那样（设计系统的组织，其产生的设计和架构等价于组织间的沟通结构），组织机构和软件架构的关系非常紧密，而在今年的研究之中，更多的则像是”逆向康威定律“：组织和团队从设计到部署都应该能够无需和其他团队进行过多牵扯精力的依赖而能够独立地完成他们的功能。
架构实践通过使用边界上下文（bounded context)和API作为Domain间解耦的重要策略，面向服务的架构应该注意解耦。实际上，有很多所谓的面向服务的架构都不能允许相互之间独立的测试和部署服务，因此团队无法获得高效率也是意料之中。
解耦非常重要，作为架构设计对持续交付的影响，除了前面提到的五大要素，在架构和团队解耦上有一些甚至比部署自动化等所起的作用都更大的要素存在，比如确认团队是否能做到诸如如下的事项：
对系统做大规模变更设计不需要团队外部某个人的批准 对系统做大规模变更设计不需要依靠其他系统或者为其做很多特意的工作 无需和团队外的其他成员做细粒度的沟通和协调工作就能完成自己的工作 独立于其他服务或者产品，可以按需部署和发布自己的产品和服务 可以在业务时间内用可以忽略的系统downtime来完成部署
“ 质
量＆ 安 全
”
在去年的介绍中，发现高绩效者仅仅在重复作业和计划外作业就比低绩效者少花22%的时间，而他们能在新的特性开发等新的作业上多花29%的时间，而今年这个趋势和结果已然存在，而且新的作业上能够投入的时间的优势进一步加深，这两个数据分别变成了21%和44%。
基 于 “ Trunk
的 开 发
”
去年，通过研究基于Trunk的开发在持续交付中所扮演的角色，我们的经验表明高绩效团队更多进行小批量的开发而不是长期存在的特性开发的分支。去年的调查结果表明如下开发实践对于提升交付绩效有好处：
每天合并代码到Trunk 使分支或者fork存在时间变短：通常为一天之内 少于三个同时实际进行的分支
同时研究也发现，团队不存在code lock也会对软件交付绩效有正向的影响。但是使用github推荐的workflow的一些开发者对此也稍微心怀疑虑，因为workflow推荐在分支上进行开发，而只需要阶段性的合并回Trunk。但是短时间存在的分支，及时合并回Trunk，至少以每日构件这样一个频度能使得持续集成的实践做的更加彻底。
而今天通过调查高中低绩效者所在团队分支存在时间，发现了如下情况： 高绩效者分支生命期最短，持续集成度也最高，分支存在和集成时间以小时计。 低绩效者分支生命期长，持续集成度也最低，分支存在和集成时间以天计。
二者也验证了去年的结果，作为推荐性的指导意见：团队应该避免分支活跃时间超过一天。如果需要花一天时间去合并和集成分支，这就是一个警示了，它提示你需要研究一下你的实践和架构了。
精 益 “ 产 品 管 理
”
去年关于产品管理的调查中，建立了一个从如下两方面的能力进行衡量精益产品管理模型： 将工作拆分为小块，而且使得其在整个交付流程中可视 收集，共享，改善客户的反馈 今年，研究将模型扩展到调查敏捷原则的影响：给予团队权利去创建和改变开发流程而不需要外部的审批。
将工作拆分为小块进行反馈和改善
精益产品管理实践会对IT绩效有着很好的促进作用，这其中就包含将工作拆分为小块，如何进行拆分，最小可用产品（MVP:minimum viable products）就是一个很好的实践，下面的这篇文章就介绍了相关的概念。 http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
在软件开发组织中，拆分出最小可用产品非常重要，因为这样你可以最小的代价，使用诸如A/B测试之类的方法，在最小影响的范围内最快地进行用户信息收集和反馈。提供了软件进行精益实践的一个好的手段。
授 权 “ 开 发 团 队
”
很多号称敏捷开发的团队实际作业时遵从其他团队所做的需求而没有提出自己意见的权利，这个限制可能会带来很多实际的问题，而最终的结果则可能是产品不会取悦客户，也无法交付所期待的业务结果。
敏捷开发的一个重要目标是在整个开发的过程中都去寻求客户的真正需要，这使得开发团队能够得到重要的信息，但是如果不管开发团队发现了什么，他们都没有任何权利对需求进行改变，创新的能力将会被极大地阉割掉。
而今年地研究则发现团队试图使用新的Idea的能力是预测组织绩效的一个重要因素。
当然，授权不是让开发者可以做任何他们想做的Idea，而是需要和一直在不断改善的DevOps实践相结合才行。
“
总 结
”
每一年的调查报告都会基于大量的数据给予DevOps的研究者以方向的指引。而在今年的报告中，通过数据，我们了解到DevOps不仅对追寻利润的企业有驱动作用，对政府型等非盈利的企业也同样有效。
而调查的结果也表明结论的一致和连贯性，在现在这个时代，软件对每个公司都变得越发的重要，而IT绩效也对组织的绩效变得愈加的重要，通过DevOps实践，更好地协调领导力、工具、自动化以及持续学习和改进的企业文化也变得越来越重要。
原创：刘淼
| 
转播
分享
淘帖
()