最近看了一些项目团队的敏捷实践分享，大家都提到了采用DevOps的方式。在推广敏捷的时候，也都会推广DevOps一体化的平台。因此我也学习了一些跟DevOps相关的书籍和资料，对敏捷跟DevOps的关系有了一些理解。
什么是DevOps
从字面上看，就是开发和运维的结合。但具体是什么呢？跟敏捷一样，DevOps并没有一个确切的定义和界限，而是一套人们在软件开发实践中的经验和方法的总结。这些经验和方法是为适应当下软件开发的特点(Volatility,Uncertainty, Complexity, Ambiguity, VUCA)而产生的。它在基于敏捷增量与迭代开发，持续改进的思想基础上，倡导了持续交付。
DevOps的产生
传统的瀑布式开发方式被看做是软件开发的第一次进化，敏捷被看做软件开发的第二次进化，而DevOps被看做是软件开发的第三次进化。
敏捷的产生，主要是为了解决需求不确定的问题。因为随着项目复杂度的增高，市场的不断变化，需求在项目的早期往往是不确定的。敏捷通过迭代和增量开发的方式，尽早的向客户交付产品功能，从而不断的获得客户的反馈，进而使需求不断明确。采用敏捷的方式，在每个迭代结束的时候，都会产生潜在可交付的软件。迭代周期短，频繁的交付，这些特点使敏捷需要强大的质量保障，因此持续集成，自动化测试，这些敏捷实践也几乎成为了敏捷的标配。虽然每个迭代结束时都要产生潜在可交付的软件，但是并不是每个迭代都会交付。主要原因，一是因为部署是一个复杂的过程，时间和人力的开销很大；二是客户可能并不需要这么频繁的升级软件，他们只是希望能看到软件的最新成果，以确定是不是他们想要的，以及接下来他们又想要什么。基于这两点原因，迭代结束时，敏捷团队通过迭代评审会向客户演示软件成果，客户根据演示的情况给出反馈意见。
这种向客户进行演示软件成果的方式主要适用于客户是确定的，并且客户不需要频繁升级软件的情况。然而在互联网行业，用户是海量的，不确定的，只有在软件交付过后，才能得到不同用户的反馈。并且用户的反馈如果没能得到及时的解决，有可能会造成用户的流失。因此，持续交付应运而生。软件部署被提到了整个软件开发生命周期中的很重要的位置。人们提出了将开发和运维紧密的结合起来，形成一条完整的开发部署流水线。DevOps也由此提出来了。
由此可见，敏捷关注的是软件生命周期的前面部分：需求，开发，测试。DevOps在此基础上，又着重关注了后面的部分：部署与发布。
DevOps技术支持
DevOps提倡的是持续交付，需要高质量做保障，以及自动化的流水线做技术支撑：
- 敏捷项目管理
- 软件配置管理
- 持续集成
- 自动化测试
- 自动化部署
持续集成和自动化测试保障了持续交付的质量。自动化部署使高频发布成为可能。灰度发布等发布策略降低了高频发布的风险。
总结
DevOps打造了端到端的持续交付流程。也体现了团队高质量的持续交付的能力。在持续交付的过程中，不断进行持续改进，从而又可以不断的提升持续交付的能力。
不过并不是所有的项目都适用高频发布。比如那些需要到客户现场去部署，或者客户并不希望频繁升级的软件项目来说，并不需要如此频繁的交付，可以根据项目的实际情况而定。
