DevOps是当前炒的很火热的概念，实践DevOps的方法涉及两个方面，一是如何持续管理需求、变更和及时处理用户反馈，通过工具固化一定的流程，有效的管理需求和变更。另一方面就是如何持续交付。
作为DevOps流程的核心实践持续交付(Continuous Delivery)在这其中能够为软件项目带来什么价值呢？本文将结合持续交付的具体实践展开分析与讨论。
入手持续交付
持续交付最基本的原则是：
提前并频繁地内部交付，将几乎所有事情自动化
持续交付最核心的实践是自动化，通过将每一次改动都提交到一个模拟产品环境中，使用严格 的自动化测试，确保业务应用和服务能符合预期，使用完全的自动化过程来把每个变更自动的提交到测试环境。
实现自动化的持续交付基于部署流水线模式。
部署流水线的目的是让软件交付过程中的每个人都能看到每个构建版本从提交到发布的整个过程，将开发机构的文化、流程和工具整合到一起，这也符合了DevOps的核心理念将开发机构的文化、流程和工具整合到一起。
下面讨论部署流水线的细节。
脚本化构建与部署
脚本化构建与部署应以迭代的方式来识别最困难的步骤，并将其自动化，沿着部署流水线，逐步完善自动化构建和部署能力。脚本化构建与部署应该遵循如下原则：
- 为部署流水线的每个阶段创建脚本，表达构建流程。
- 使用同样的脚本向所有环境部署，保证在所有环境上都能运行。
- 确保部署过程是幂等的。
- 增量式部署。
提交
提交阶段发生在像版本控制库提交代码，是流水线的入口。提交阶段应遵循如下原则：
- Dev保证本地构建成功后提交
- 测试不通过令提交失败，并记录错误信息，反馈Dev尽快修复，Dev对自己的问题负责
- 提交失败后可以回滚版本
- 降低构造测试环境的复杂性，保证测试代码整洁有效性。
自动化验收测试
单元测试不能保证捕获所有问题，因此需要验收测试来保证软件质量。频繁的手工测试带来高昂成本，采用自动化验收测试便于频繁发布软件。
自动化验收测试使得团队成员都关注于真正的工作：业务价值，为软件能否满足标准提供了更高得信心，快速向开发团队反馈问题，便于软件大规模重构。
非功能性需求测试
非功能需求测试包括容量、吞吐量以及性能测试。
将非功能性需求加入到部署流水线上，便于软件设计执行实验场景来帮助诊断预测问题。
对于非功能需求，过早地关注容量优化是低效且昂贵的，有可能造成过度设计，除非性能有问题，不在代码可读性上让步。
发布
频繁地将软件发布到不同的测试环境中，能够降低发布的风险，降低上线压力。
发布过程将组织各部门联系起来：运维团队，开发团队，测试团队，技术支持团队，交付团队，促进交流合作。
持续交付对于运维的改变
DevOps将敏捷方法引入到系统管理与运营，有两点主要原则：
- 强调合作
- 利用敏捷技术对基础设施进行有效管理
运维负责将代码部署到生成环境中，持续交付从一开始就让运维参与进来，两者共同的利益是
让发布有价值、稳定得软件成为一件低风险的事
持续交付的核心实践 尽可能频繁的发布 保证了这一点，从而成为了DevOps的关键步骤。
自动化环境管理
对于运维人员的工作，关键的痛点在于部署系统到不同配置的大量基础设施上，对基础设置的管理往往利用脚本管理，修改基础设施的技术也应该是发布的一部分。
将基础设施的配置自动化，纳入流水线并配置测试会大大便于运维的部署管理工作。
另一种方案，使用docker进行持续集成
在业务不断增长过程中，企业的组件也随之不断扩张，随之带来了对基础设施的复杂配置管理工作。采用自动化部署配置管理无疑产生巨大成本，使用Docker——以“容器化”的方式去部署应用。 Docker像集装箱一样，打包了所有依赖，再在其他服务器上部署很容易，不至于换服务器后发现各种配置文件散落一地，这样就解决了编译时依赖和运行时依赖的问题。
利用Docker进行持续集成的流程如下：
- 开发者提交代码；
- 触发镜像构建；
- 构建镜像上传至私有仓库；
- 镜像下载至执行机器；
- 镜像运行。
价值
贯穿持续交付始终的是自动化手段，这也恰恰是软件行业所追求的，自动化的交付过程带来了诸多益处：
- 快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
- 快速发布。能够应对业务需求，并更快地实现软件价值。
- 编码->测试->上线->交付的频繁迭代周期缩短，同时获得迅速反馈；
- 高质量的软件发布标准。整个交付过程标准化、可重复、可靠，
- 整个交付过程进度可视化，方便团队人员了解项目成熟度；
- 更先进的团队协作方式。从需求分析、产品的用户体验到交互 设计、开发、测试、运维等角色密切协作，相比于传统的瀑布式软件团队，更少浪费。
- 更平滑的开发过程，减少上线风险，增强团队信心。
