一、概述开发模式
无论是瀑布式开发、敏捷式开发还是DevOps，整个流程都分为设计、开发、测试和部署四个部分，只不过各个部分的开始和结束时间节点不同。如下图所示：
开发模式的差异.png
从瀑布式开发到敏捷开发再到DevOps，各个阶段的切换速度越来越快，瀑布式开发和敏捷开发的运维部署工作都是放到最后，而DevOps结合敏捷开发思想，将部署工作也敏捷起来。
开发模式.png
二、瀑布式开发
2.1 简述瀑布式开发
瀑布式开发是早期被广泛采用的软件开发模型。要求有明确的需求，按照需求一步步做好规划，每一阶段工作的完成是下一阶段开始的前提，每一阶段都要进行严格的评审，保证各阶段的工作做得足够好时才允许进入下一阶段，它适用于需求明确的项目。
最大的风险是，当产品研发完成后，到了产品测试阶段如果发现了问题，或者发现其无法满足市场需求，那么就需要重新开发，甚至需要重新规划产品。
三、敏捷式开发
3.1简述
敏捷开发是一种以用户需求进化为核心、倡导拥抱变化、循环迭代、循环渐进的开发方法。首先把用户最关心的软件原型做出来并交付给用户，用户在实际场景中发现问题并给予反馈，研发人员快速修改弥补需求中的不足。上述过程不断迭代，直到用户满意。
敏捷追求“更早地交付价值，更灵活地应对变化”，适用于需求不明确、创新性或者需要抢占市场的项目，特别适合互联网项目。
3.2 原则
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件来使客户满意。
- 欣然面对需求变化，即使到了开发的后期也一样。敏捷过程利用变化为客户创造竞争优势。
- 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
- 业务人员和开发人员必须相互合作，项目中的每一条都不例外。
- 激发个体的斗志，以他们为核心搭建项目，提供所需的环境和支援，辅以信任，从而达成目标。围
- 无论团队内外，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
- 可工作的软件是进度的首要进度标准。
- 敏捷过程倡导可持续开发。负责人、开发者和用户要能够共同维持其步调稳定连续。
- 不断地追求技术卓越和良好设计，会增强敏捷能力。
- 以简洁为本，极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自于自组织的团队。
- 团队定期地反思如何能够提高效能，并依此调整自身的举止表现。
3.3 宣言
- 个体和交互 胜过 过程和工具
- 可以工作的软件 胜过 面面俱到的文档
- 客户合作 胜过 合同谈判
- 响应变化 胜过 遵循计划
四、DevOps
4.1 简述
DevOps是一种方法论，DevOps = Development + Operations，即开发团队和运维团队一体化，尽可能地为公司创造更多价值。
DevOps是一种软件开发实践，它将人员、流程和技术结合在一起，以交付持续的价值。该方法分为计划和跟踪、开发、生成和测试、交付以及监视和操作。
DevOps.png
DevOps的独特之处在于开发、IT运营、质量工程和安全团队协同工作，在发布新产品、版本或更新所涉及的所有任务中创造效率。
DevOps将开发和运营合并为一个团队，专注于快速交付和稳定的基础架构。其目标包括：
- 将完成的代码快速交付到生产环境；
- 最小的生产故障。
- 从故障中立即恢复。
4.2 价值观
DevOps是一种文化，是一种软件开发的方式或者基础设施的方式，也是一种构建和部署软件和应用的方式。它假设开发和运维之间没有隔阂，他们一起合作，没有矛盾。
DevOps基于其它两个领域的实践：精益和敏捷。DevOps不是一个公司内的岗位或角色；它是一个组织或团队对持续交付、持续部署和持续集成的坚持不懈的追求。三种方式定义的DevOps的理念：
- 第一种：流程原则
- 第二种：反馈原则
- 第三种：持续学习原则
4.3 原则
1、持续交付的八大原则
DevOps持续交付的八大原则对可运维性给出了这样的定义，在企业中研发和运维体系必然需要相互配合，开发团队负责功能性需求实现的同时，在架构和编码上注重非功能性需求的实现，测试团队和运维团队将围绕着各自职能的需求，规划与建设DevOps流水线中对应的工具系统，加速企业IT价值链的流转，以为企业创造更大的商业价值。
- 为软件的发布创建一个可重复且可靠的过程：标准化发布操作，建立可靠的脚本/工具，并用自动化流程实现编排。
- 将几乎所有事情自动化：区分场景，将计划内任务实现自动化运维。
- 把所有的东西都纳入版本控制：可描述、可度量、可监督，并纳入运维平台管理。
- 提前并频繁地做出让你感到痛苦的事情：让错误尽早的暴露，并修复它。
- “DONE”意味着“已发布”：交付到用户受众才是完成。
- 交付过程是每个成员的责任：协同合作，减少等待的浪费。
- 持续改进：闭环，不断提升能力。
2、提倡的原则
- 从瓶颈入手
- Start Small：从小做起
- 痛苦的事情优先解决
- 工具也是一种文化
- 自动化别人，先自动化自己
- 价值拉动，而非事务驱动
- 构建指标，驱动DevOps落地。
- 创建从开发过程下游至上游的反馈环。
- 强调全局优化，避免局部优化
- 持续做试验和学习的文化，通过反复实践来达到精通。
4.4 DevOps包含一些工具链
DevOps实践涉及到开发部门以及软件研发的整个生命周期，这意味着在整个开发生命周期中，涉及到一大批新旧工具，包括从规划、编码、测试、发布、监控等自动化的流程工具。
工具链.png
DevOps融合了一系列基本原则和实践的方法论，并从这些实践中派生出了各种工具。这些工具体现在软件开发和交付过程的不断阶段。
- 编码：代码开发和审阅，版本控制工具、代码合并工具
- 构建：持续集成工具、构建状态统计工具
- 测试：通过测试和结果确定绩效的工具
- 打包：成品仓库、应用程序部署前暂存
- 发布：变更管理、发布审批、发布自动化
- 配置：基础架构配置和部署，基础架构即代码工具
- 监控：应用程序性能监控、最终用户体验
4.5 实践DevOps需要建立哪些能力
1、不可或缺的自动化能力
主要体现在三点上：
- 自动化比手动快
- 工具不会像人一样容易犯错误
- 通过自动化按照定义执行确保每次执行的一致性
2、建立持续支付能力
主要体现在三点上：
- 通过统一的部署流水线将从代码提交到交付给用户的整个过程高度可视化出来，信息透明；让开发、测试和运维以高度一致的方式工作在同一个流水线上，真正建立起协作。
- 每一次的软件变更在这个完整的流水线中得到充分的验证，尽早发现有缺陷的变更。
- 将一些必不可少的控制环节内建到自动化过程中，比如质量保障过程、过程度量、过程审计信息等，从而弱化很多传统依靠人为检查的管理流程。
3、利益共同体的合作文化
以提高业务响应效率出发，要有一荣俱荣、精诚合作、共同进步的态度。
合作文化.png
DevOps成功的关键在于文化转变，除了上面提到工具，组织文化的转变也同等重要，我们总结出了很多DevOps的其他因素，比如人（People）的思想和思考方式、开发和运维的流程（Process）、精益（Lean）、自动化（Automation）、测量（Measurement）。
在组织文化方面，DevOps推崇：
- 尊重（Respect）
- 正视失败（Healthy attitude about failure）
- 不埋怨（Avoiding Blame）
- 精益求精
- 工程质量文化
- 快速验证文化
- 客户导向文化
4.6 最佳实践手段：CI/CD
DevOps是CI/CD思想的延伸，CI/CD则是DevOps的技术核心，如果没有CI/CD，没有自动化测试，DevOps是没有任何意义的。所以说DevOps是以CI/CD为基础来优化程序的开发、测试、运维等各个不同环节。
1、CI
CI：持续集成，是一种开发实践，它倡导团队成员需要频繁的集成他们的工作，每次集成都通过自动化构建（包括编译、构建、自动化测试）来验证，从而尽快地发现集成中的错误。让正在开发的软件始终处于可工作的状态，让产品快速迭代，同时还能保持高质量。
2、CD
CD包含了两层内容：持续交付和持续部署。
持续交付是持续集成的延伸或者看作持续集成的下一步，它将集成后的代码部署到类生产环境，确保可以以可持续的方式快速向客户发布新的更改。如果代码没有问题，可以手工部署到生产环境中。它强调的是，不管怎么更新，软件是随时随地可以交付的。
持续部署是持续交付的下一步，在持续交付的基础上，由开发人员或运维人员自助式的定期向生产环境部署稳定的构建版本，持续部署的目标是代码在任何时刻都是可部署的，并可自动进入到生产环境。
持续交付是指团队确保每个变更可以部署至生产环境，但也许并不需要实际部署，这通常可能是处于业务方面的原因。而持续部署是指每个变更可以自动部署到生产环境。
五、比对瀑布、敏捷、DevOps
5.1 瀑布的优劣
瀑布的优劣.png
5.2 敏捷的优劣
敏捷的优劣.png
5.3 DevOps的优势
devops的优势.png
5.4 敏捷与DevOps共存
关于 DevOps 和敏捷，最重要的一点是它们不是互斥的。
DevOps 是一种文化，促进所有参与软件开发和维护的参与者之间的协作。
敏捷可以被描述为一种开发方法，旨在需求不断变化的现实中维护工作效率和驱动发布。
尽管 DevOps 和敏捷是不同的，但是如果将这两种方法结合使用，将会带来更高的效率和更可靠的结果。DevOps是敏捷的有效补充，是将运维纳入产品开发过程的思维方式，是敏捷开发方法论的升级，更强调自动化工具的实现与应用，以帮助实现软件的快速迭代。
六、未来发展
DevOps是精益思想应用在IT领域的必然结果，源起于开发侧的敏捷运动，由于端到端的系统优化需求，发展到开发、测试、运维的联动。
从其发展脉络，可以发现DevOps的必然发展方向，那就是向业务侧延伸。
6.1 BizDevOps
业务是产品开发和运维的源头，完整的价值流必须从源头开始。这不是预测，而是正在发生的事实，大部分DevOps的实施都已经将业务侧包含在内，成为BizDevOps。
BizDevOps需要达成的目标如下所示：
- 需求管理：分别从业务代表/产品经理/开发人员/测试人员等视角提供符合各自角色的需求看板
- 链路打通：打通从需求到设计，研发，测试，运维，运行的信息链条
- 价值流可视化：从端到端可视化地传递价值流
- 促进交付质量：设置验收标准，统计标准达成率，反馈需求最终交付质量
6.2 MLDevOps
机器学习（ML）系统是一种软件系统，所以DevOps也适用于构建和运维可靠的ML系统。然而，ML系统与其他软件系统有以下不同：
- 团队技能：一个ML项目中，通常有专注于数据分析，模型开发和实验数据科学家和ML研究人员，他们对构建生产级别的服务可能没有太多经验。
- 开发：ML本事带有实验性质。你可能会用不同的特征、算法、建模方法、参数设置，去更快的解决问题。最大的挑战是追踪哪种方式有效果或者没有效果，并且用最可复用的代码保证结果可重现。
- 测试：测试ML系统比测试其它软件系统更复杂。你需要数据验证，模型的评价标准还有模型验证。
- 部署：在ML系统中，部署不会像部署一个线下模型作为一个预测服务那样简单。还要有一个可以重复训练模型的多阶段流水线。并可以将数据科学家在部署之前手动完成的步骤自动化，以训练和验证新模型。
- 投产：ML模型性能可能会降低，这不仅是由于编码不理想，还因为不断扩充的数据配置文件。模型比传统软件系统更可能发生偏离。因此您需要跟踪数据的汇总统计并监控模型的在线性能，以便在值偏离您的预期时发送通知或回滚。
ML系统和其他软件系统在源代码控制的持续集成、单元测试、集成测试以及软件模块或包的持续交付也有一些显着的差异：
- CI 不再只是测试和验证代码和组件，还包括测试和验证数据、数据模式和模型。
- CD 不再是关于单个软件包或服务，而是一个可以自动部署另一个模型预测服务的流水线。
- CT（持续训练）是机器学习系统独有的特性，包含自动化重复训练和为模型提供服务。
6.3 APPDevOps
客户端涉及H5、Android、iOS，手工作业比较多，管理愈发困难。DevOps可以通过自动化通过减少手工作业，实现一站式构建与运维平台。
- H5应用的离线包构建以及发布
- Android应用的安装包构建
- IOS应用的安装包构建
七、小结
本文是本人整理总结的，内容来源于网络与书籍，如果引用作者的文章，可以联系我，我会在来源进行备注。
如果需要給我修改意见的发送邮箱：erghjmncq6643981@163.com
资料参考：《敏捷软件开发》
转发博客，请注明，谢谢。
网友评论