最近的一篇文章概述了DevOps运动的历史，并识别出了这个过程中的两个阶段。第一个阶段关注于增强传统工程团队（Dev、QA以及Ops）内部的协作，而正在出现的第二个阶段则以此为基础，致力于提升工程团队与非工程团队之间的协作，如销售和市场团队。
DevOps正式起源于2008年，随后在2011年的一份报告对其进行了总结，并且认为DevOps并不仅仅是一时的狂热，这被称之为1.0运动，它试图将持续的软件交付以流水线的形式组织起来，关注于增加协作和信任，并采用一定的实践来促进它的实现。目前的实践和工具证明了该项运动的成熟性。
在去年的DevOps状态报告中，描述现状的关键点可以总结为：更快更频繁地部署到生成环境、对于故障具有更高的可见性以及更快的故障修复速度。
DevOps的下一阶段是由工程团队与非工程功能团队（如销售）之间更为密切的协作来驱动的。客户和市场会不断发生变化，工程团队必须要响应这种持续的变化，要随时准备部署新特性以配合市场和销售活动的开展。
与第一阶段类似，有一些实践和工具的组合已经开始涌现，以促进该过程的实现。其中包括ChatOps、特性/任务的管理工具以及仪表盘。这里的关注点在于提升速度的同时不能损害系统的稳定性。
特性标记（feature flag）被视为应对这一需求的关键机制。在传统的软件发布过程之中，发布到生产环境中的代码与某个终端用户可用的特性之间存在着一对一的关联关系。特性标记将这种关联关系进行了解耦，它增加了一项功能，那就是只有在设置标记的情况下，特定的特性才是可用的，而这种设置可以在运行时进行。
将功能发布与代码部署进行解耦会带来很多的好处：
代码能够在特性尚未完成的时候就进行发布，只需把未完成的特性关闭即可； A/B测试以及beta测试； 可以将终端用户划分为不同的组，如超级用户与正常用户、付费用户与免费用户。
特性标记需要在工程团队中形成良好的纪律性，软件也需要经过深思熟虑的设计。有一些要进行大规模功能部署的组织已经采用了特性标记的做法，如Facebook和Etsy。
本文转自d1net（转载）
