认识达内从这里开始

我们在上文中给大家简单介绍了DevOps编程开发的一些基本知识与常见的开发工具等内容，而今天我们就再来了解一下，DevOps编程在实现敏捷开发上的发展趋势都有哪些变化。

工具演变

促进特定DevOps实践(在这里是将部署与发布分离开来)的产品是有市场的。这种做法是A/B测试和金丝雀部署等活动不可或缺的一部分，而这些活动已被视为降低风险和支持试验的有力方式。我期望支持DevOps实践的工具会继续出现，否则我们就需要自己编码了。

虽然这并不是一个新趋势，但可以肯定的是，像AmazonWebServices(AWS)、Azure和谷歌云平台(GCP)这样的服务将会继续推出新的服务，相互竞争，并从遗留基础设施那里获得市场份额。在提供的产品种类和控制的市场份额方面，Azure和GCP仍在追赶，但预计它们会紧跟AWS的步伐。Kubernetes即服务等产品有助于降低管理底层基础设施的复杂性。预计其他类型的复杂系统将继续打包进这种立即可用的应用程序里。

数据科学

来自Puppet和谷歌的DevOps现状报告为使用数据科学来评估开发实践的有效性设立了标准。希望可以看到更多的工具开始将分析和数据科学集成到它们的产品中。也希望看到更多的团队请求并利用这些功能来促进实验，并验证这些实验的结果。

多年来，营销等业务职能部门一直在使用A/B测试并对其有效性进行量化。有大量面向营销的工具已经被高度调优，以提供点击率、采用率、网站停留时间、投资回报等指标。其中，存在时间长的是谷歌分析，但有大量的工具可供营销人员选择。颇具讽刺意味的是，在诸如A/B测试和确保用户采用应用程序等实践方面，IT团队却成了迟到者。经常是由业务团队跟踪IT部门创建的应用程序的采用情况。但是，内部IT部门是有可能做出改进以满足用户需求的部门。

希望可以看到内部开发团队更多地使用监控工具，甚至是嵌入式反馈和用户满意度调查工具。这些实践有助于缩小终用户和开发团队之间的距离，就像营销团队多年来一直努力缩小公司和客户之间的距离一样。这种反馈非常有效，因为之前每次你想要征求用户的反馈时，都会涉及业务分析人员，导致效率低下。选择性反馈措施也存在样本偏差的问题。

精益和敏捷

DevOps的目标是“实现敏捷”，确保团队拥有真正敏捷的技术能力，而不仅仅是缩短他们的计划和工作节奏。重要的是，DevOps也有精益的血统。这意味着需要关注端到端生命周期、流程优化，并考虑如何在消除浪费方面进行改进，而不是仅仅增加能力。有大量的组织和团队仍然只是迈出了这个过程的一步。对于他们来说，尽管术语和概念在一开始可能让人觉得透不过气来，但他们可以从许多经过良好发展的选项中受益，以满足他们的开发生命周期的需要。我预计，许多软件工具将会在易用性方面进行优化，并继续在可用性和UI外观方面进行竞争。

尽管大多数早期的DevOps方案都是严格基于脚本和配置文件的，但是，新产品可以帮助可视化流程和依赖关系，并且可以被组织更广泛的部分轻松理解。特别是当公司试图抓住CIO、CTO和其他组织决策者的注意力并争取资金分配时，减少工具实际的UI与可视化及营销工作之间的差异变得越来越重要。漂亮的图形化工具才能把自己卖出去(卖给业务和技术用户)。价值流映射和交付管道是可视化交付流程特别流行而有效的方法，同时还提供了对度量指标和监控的日常访问。

系统集成商

具备这项技能的人员显然无法满足DevOps实践的市场和需求。因此，系统集成商将继续帮助团队提升这方面的技术和流程，在某些情况下，甚至帮助管理组织的开发生命周期。DevOps现状报告的研究表明，职能外包预示着低效，因此，组织在将特定的活动委派给外部承包商时要特别小心，例如测试或部署。除非特别小心，否则职能外包就违背了DevOps的精神，DevOps的核心是统一所有相关利益干系人(从开发人员到运维人员)的目标，共享可见性和技术。

在内部缺乏人才的情况下，咨询合作伙伴是获得帮助的一种极其有效的方式。但这必然会引入组织边界的问题，除非咨询师深入组织内部，与全职员工长期共事。依靠DevOps顾问来帮助你采用技术、改进流程、设计指标等等。但是，外包流程中处于关键生产路径上的特定部分(例如测试)要非常谨慎。

将特定应用程序的整个开发过程交给咨询公司可能会更好。但是，要考虑它的长期生命周期，以及你希望公司今后如何维护应用程序。按照从项目到产品的精神，让一个团队构建应用程序，让另一个单独的团队维护应用程序是有风险的。将你在团队中构建的知识视为组织架构的关键组成部分。在上线之后从你的架构中删除大量内容是鲁莽的，同样，在上线之后从你的团队中删除大量知识也是不明智的。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。