DevOps核心实践--持续交付

DevOps的核心是软件开发和交付理念，强调产品管理，软件开发和运营/系统管理员团队之间的沟通和协作，并与业务目标紧密结合。它通过建立一种文化（与相关实践）来自动化和监控软件集成，测试，部署和基础架构变更的过程来支持这一点，其中构建，测试和发布软件可以快速，频繁且更可靠地发生。

我们相信你们很多人会认为这听起来很像持续交付的原则 - 你会是对的！但是，持续交付只是DevOps工具箱中的一个工具。它是一个必不可少且有价值的工具，但要真正在设计，实施和运营持续交付构建管道方面取得成功，通常需要在整个组织中获得一定程度的支持，这就是与之相关的实践。 DevOps闪耀。

部署流水线 deployment pipeline
指软件从版本控制库到用户手中这一过程的自动化表现形式。

持续交付是指以可持续的方式将各类变更（包括新功能、缺陷修复、配置变化、实验等）安全、快速、高质量地落实到生产环境或用户手中的能力。
持续交付的分级技术要求包括：配置管理、构建与持续集成、测试管理、部署与发布管理、环境管理、数据管理、度量与反馈等，如图所示。

上图涉及的基本概念解释如下:
测试管理
测试管理是指一个过程，通过该过程，所有与测试相关的过程、方法被定义。在产品投入生产性运
行之前，验证产品的需求，尽可能地发现并排除软件中的缺陷，从而ᨀ高软件的质量。
测试管理又可以分为测试分层策略、代码质量管理、自动化测试等多个维度表述。

代码质量管理
代码质量管理是在软件研发过程中保证代码质量的一种机制，当代码变更后，可以对代码质量进行
检查、分析,给出结论和改进建议，对代码质量数据进行管理，并可以对代码质量进行追溯。

自动化测试
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程，在预设条件下运行系统或应用
程序，执行测试并评估测试结果，以达到节省人力、时间或硬件资源，ᨀ高测试效率和准确性。

部署与发布管理
部署与发布泛指软件生命周期中，将软件应用系统对用户可见，并ᨀ供服务的一系列活动，包括系
统配置，发布，安装等。整个部署发布过程复杂， 涉及多个团队之间的协作和交付，需要良好的计划和
演练保证部署发布的正确性。
其中部署偏向技术实践，即将软件代码，应用，配置和数据库变更应用到测试环境、准生产环境和
生产环境的过程。发布偏向于业务实践，指将部署完成的应用软件功能和服务正式对用户可见，ᨀ供线
上服务的过程。 部署和发布的有机结合，实现了软件价值向最终用户的交付。

部署与发布模式
部署和发布模式关注交付过程中的具体实践，将部署活动自动化并前移到研发阶段，通过频繁的演
练和实践部署活动，成为研发日常工作的一部分，从而减少最终部署的困难和不确定性，可靠可重复的
完成部署发布任务。部署发布模式通过合理规划，分层实施，一方面减少软件最终上线交付风险，同时
可及时获取用户信息反馈，帮助持续改善整个软件交付过程和软件功能定义。

持续部署流水线 是DevOps的核心实践，通过可靠可重复的流水线，打通端到端价值流交付，实现交
付过程中各个环节活动的自动化和可视化。部署流水线通过将复杂的软件交付流程细分为多个阶段，每
个阶段层层递进，ᨀ升软件交付质量信心，并且在流水线过程中ᨀ供快速反馈，减少后端环节浪费。
可视化流水线可以增强跨组织的协同效率，ᨀ供有效的信息共享平台，从而统一组织目标，并且不
断识别流水线中的约束点和瓶颈，以及潜在的自动化及协作场景，通过持续改进而不断ᨀ升软件交付效
率。

环境管理

环境作为DevOps持续敏捷交付过程中最终的承载，环境的生命周期管理、一致性管理、环境的版本
管理都变得非常重要。环境管理是用最小的代价来达到确保一致性的终极目标。

数据管理
系统开发过程中为了满足不同环境的测试需求，以及保证生产数据的安全，需要人为准备数量庞大
的测试数据， 需保证数据的有效性以适应不同的应用程序版本。 另外应用程序在运行过程中会产生大量
数据，这些数据天生有状态，同应用程序本身的生命周期不同，作为应用最有价值的内容需要妥善保存，
并随应用程序的升级和回滚进行迁移。

测试数据管理
测试数据需要满足多种测试类型的需求（手工测试，自动化测试），覆盖正常状态，错误状态和边
际状态，测试数据需同时满足测试效率和数据量的要求。测试数据的输入需要受控，并运行在受控环境
中，保证输出的有效性，同时由于持久数据的必要行，要避免数据被未授权的篡改，以影响测试结果的
客观一致性。为了模拟类生产环境系统运行情况， 常采用仿生产环境数据，此类测试数据在使用时需要
注意数据安全，避免敏感用户数据泄露，及时进行数据清洗和漂白。

度量与反馈
DevOps基于精益思想发展而来，其中持续改进是精益思想的核心理念之一。 DevOps主张在持续交付
的每一个环节建立有效的度量和反馈机制，其中通过设立清晰可量化的度量指标，有助于衡量改进效果
和实际产出，并不断迭代后续改进方向。另外设立及时有效的反馈机制，可以加快信息传递速率，有助
于在初期发现问题，解决问题，并及时修正目标，减少后续返工带来的成本浪费。度量和反馈可以保证
整个团队内部信息获取的及时性和一致性，避免信息不同步导致的问题，明确业务价值交付目标和状态，
推进端到端价值的快速有效流动。

度量指标
度量指标的拣选和设定是度量和反馈的前ᨀ和基础，科学合理的设定度量指标有助于改进目标的达成。在拣选度量指标时需要关注两个方面，即度量指标的合理性和度量指标的有效性，合理性方面依托于对当前业务价值流的分析，从过程指标和结果指标两个维度来识别DevOps实施结果，以及整个软件交付过程的改进方向；有效性方面一般遵循SMART原则，即指标必须是具体的、可衡量的、可达到的、同其他目标相关的和有明确的截止时间，通过这五大原则可以保证目标的科学有效。

DevOps是当前炒的很火热的概念，实践DevOps的方法涉及两个方面，一是如何持续管理需求、变更和及时处理用户反馈，通过工具固化一定的流程，有效的管理需求和变更。另一方面就是如何持续交付。

作为DevOps流程的核心实践持续交付(Continuous Delivery)在这其中能够为软件项目带来什么价值呢？本文将结合持续交付的具体实践展开分析与讨论。

构建与持续集成
构建是将软件源代码通过构建工具转换为可执行程序的过程，一般包含编译和链接两个步骤， 将高级语言代码转换为可执行的机器代码并进行相应的优化，升运行效率。
持续集成是软件构建过程中的一个最佳实践， 在版本控制的基础上，通过频繁的代码提交，自动化构建和自动化测试，加快软件集成周期和问题反馈速度，从而及时验证系统可用性。

构建实践
构建实践关注软件代码到可运行程序之间的过程，通过规则、资源和工具的有效结合，提升构建质量和构建速度，使构建成为一个轻量级，可靠可重复的过程。同时构建产物被明确标识管理，采用清晰的规则定义版本号和目录结构有助于团队成员可以随时获取到可用版本，以及版本相关的信息，快速验证回溯版本变更。

持续集成
持续集成是软件工程领域中的一种最佳实践，即鼓励研发人员频繁的向主干分支提交代码，频率为至少每天一次。每次ᨀ交都触发完整的编译构建和自动化测试流程，缩短反馈周期，出现问题第一时间进行修复，从而保证软件代码质量，减少大规模代码合并的冲突和问题，让软件随时处于可发布状态。

入手持续交付
持续交付最基本的原则是：

提前并频繁地内部交付，将几乎所有事情自动化

持续交付最核心的实践是自动化，通过将每一次改动都提交到一个模拟产品环境中，使用严格 的自动化测试，确保业务应用和服务能符合预期，使用完全的自动化过程来把每个变更自动的提交到测试环境。
实现自动化的持续交付基于部署流水线模式。

CD pipeline
部署流水线的目的是让软件交付过程中的每个人都能看到每个构建版本从提交到发布的整个过程，将开发机构的文化、流程和工具整合到一起，这也符合了DevOps的核心理念将开发机构的文化、流程和工具整合到一起。
下面讨论部署流水线的细节。

脚本化构建与部署
脚本化构建与部署应以迭代的方式来识别最困难的步骤，并将其自动化，沿着部署流水线，逐步完善自动化构建和部署能力。脚本化构建与部署应该遵循如下原则：

为部署流水线的每个阶段创建脚本，表达构建流程。
使用同样的脚本向所有环境部署，保证在所有环境上都能运行。
确保部署过程是幂等的。
增量式部署。
提交
提交阶段发生在像版本控制库提交代码，是流水线的入口。提交阶段应遵循如下原则：

Dev保证本地构建成功后提交
测试不通过令提交失败，并记录错误信息，反馈Dev尽快修复，Dev对自己的问题负责
提交失败后可以回滚版本
降低构造测试环境的复杂性，保证测试代码整洁有效性。
自动化验收测试
单元测试不能保证捕获所有问题，因此需要验收测试来保证软件质量。频繁的手工测试带来高昂成本，采用自动化验收测试便于频繁发布软件。
自动化验收测试使得团队成员都关注于真正的工作：业务价值，为软件能否满足标准提供了更高得信心，快速向开发团队反馈问题，便于软件大规模重构。

非功能性需求测试
非功能需求测试包括容量、吞吐量以及性能测试。
将非功能性需求加入到部署流水线上，便于软件设计执行实验场景来帮助诊断预测问题。
对于非功能需求，过早地关注容量优化是低效且昂贵的，有可能造成过度设计，除非性能有问题，不在代码可读性上让步。

发布
频繁地将软件发布到不同的测试环境中，能够降低发布的风险，降低上线压力。
发布过程将组织各部门联系起来：运维团队，开发团队，测试团队，技术支持团队，交付团队，促进交流合作。

持续交付对于运维的改变
DevOps将敏捷方法引入到系统管理与运营，有两点主要原则：

强调合作
利用敏捷技术对基础设施进行有效管理
运维负责将代码部署到生成环境中，持续交付从一开始就让运维参与进来，两者共同的利益是
让发布有价值、稳定得软件成为一件低风险的事
持续交付的核心实践 尽可能频繁的发布 保证了这一点，从而成为了DevOps的关键步骤。

自动化环境管理
对于运维人员的工作，关键的痛点在于部署系统到不同配置的大量基础设施上，对基础设置的管理往往利用脚本管理，修改基础设施的技术也应该是发布的一部分。
将基础设施的配置自动化，纳入流水线并配置测试会大大便于运维的部署管理工作。

另一种方案，使用docker进行持续集成
在业务不断增长过程中，企业的组件也随之不断扩张，随之带来了对基础设施的复杂配置管理工作。采用自动化部署配置管理无疑产生巨大成本，使用Docker——以“容器化”的方式去部署应用。 Docker像集装箱一样，打包了所有依赖，再在其他服务器上部署很容易，不至于换服务器后发现各种配置文件散落一地，这样就解决了编译时依赖和运行时依赖的问题。
利用Docker进行持续集成的流程如下：

开发者提交代码；
触发镜像构建；
构建镜像上传至私有仓库；
镜像下载至执行机器；
镜像运行。
价值
贯穿持续交付始终的是自动化手段，这也恰恰是软件行业所追求的，自动化的交付过程带来了诸多益处：

快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
快速发布。能够应对业务需求，并更快地实现软件价值。
编码->测试->上线->交付的频繁迭代周期缩短，同时获得迅速反馈；
高质量的软件发布标准。整个交付过程标准化、可重复、可靠，
整个交付过程进度可视化，方便团队人员了解项目成熟度；
更先进的团队协作方式。从需求分析、产品的用户体验到交互 设计、开发、测试、运维等角色密切协作，相比于传统的瀑布式软件团队，更少浪费。
更平滑的开发过程，减少上线风险，增强团队信心。