- 什么是DevOps?
- “DevOps”是英文单词“Development”和“Operation”的组合,即开发和运维的结合。
- 目前DevOps并没有权威的定义,但得到大部分人认可的是,DevOps已经成为一种文化价值观和实践方法。DevOps价值观的呈现和实践并不依赖于特定的软件,通过合适的软件工具组合可以更容易实现这一价值观。
- DevOps使得业务可以更快地运营,更快地应对变化。
1、DevOps简介
- 谈到DevOps,就不得不回顾一下软件开发模型(SoftwareDevelopmentModel)的历史。软件开发模型是指软件开发全部的过程、活动和任务的结构框架。它包括需求、设计、编码和测试等阶段,有时也包括维护阶段。软件开发模型能清晰、直观地表达软件开发全过程,明确要完成的主要活动和任务。本章会介绍比较典型的瀑布模型、迭代模型、敏捷模型进行说明,以及如何演进到DevOps。
1.1、软件开发模型
- 爆布模型严格遵循预先计划的需求分析、设计(可细分为系统设计、概要设计、详细设计)、编码、集成、测试的步骤顺序进行。上一阶段的成果输出成为下一阶段的工作输入,阶段之间通过交付大量的文档进行传递。严格的分级、分阶段导致团队的灵活性降低,使项目难以响应需求的变化,难于调整或调整的代价极高。
- 迭代式开发模型每次只设计和实现这个产品的一部分,在迭代式开发方法中,整个开发工作被组织为一系列短小的、固定长度(如4周)的小周期,被称为一系列的迭代。每一次迭代中都会包含完整的需求分析、设计、编码与测试,再通过反馈来细化需求,并开始新一轮的迭代。这种方式弥补了瀑布模型中的一些弱点,加快了对变更的响应速度,可以提前识别问题,从而降低了项目风险,提升了项目成功率和生产率。
- 敏捷软件开发模型,是一种从20世纪90年代开始逐渐引起广泛关注的新型软件开发方法,能应对需求的快速变化。敏捷开发强调开发人员与业务专家之间的紧密协作、强调面对面的沟通、强调频繁交付新的软件版本、强调能够很好地适应需求变化的代码编写和团队组织方法,也更加注重软件开发中人的作用。
- 瀑布式开发,从需求到测试,要求每一个开发阶段都要做到最好,特别是前期阶段,设计得越完美,提交后的成本损失就越少。
- 迭代式开发,不要求每一个阶段尽善尽美,而是先实现主要功能,再通过持续反馈逐步完善。
- 敏捷开发,相比迭代式开发,两者都强调在较短的开发周期交付软件,但敏捷开发的周期可能更短,更强调团队的高度协作,强调适应性而非预见性。
1.2、DevOps发展历史
- 自从人类创造了计算机,就诞生了程序员(Programmer)这个职业,从为计算机编写程序以利用其计算能力,逐渐演变为专职的实现特定功能的开发人员(Developer)。后来由于存在大量的软硬件资源需要维护,又逐渐出现专职的运维人员(Operation)这一职业。
- 开发人员关注怎样更快实现功能并交付开发产品,运维人员关注如何使产品运行得更加稳定。Dev和Ops的矛盾主要是面向适应性的敏捷软件交付和面向经验性的传统运维之间的矛盾。而DevOps打破了开发和运维两个部门、团队之间的障碍墙。
- 2009年6月,在Velocity大会上,一个名为《10 + Deploys Per Day: Dev and Ops Cooperation at Flickr》的演讲成为本次大会最大的亮点,几乎所有和DevOps相关的资料都引用该演讲作为DevOps出现的标志事件。这个演讲提出:“以业务敏捷为中心,构造适应快速发布软件的工具和文化。”
- 第一届DevOpsDays于2009年10月在比利时根特举行,这次聚会开创了DevOps活动的先河。本次活动尽管只通过推特(Twitter)发起和召集,却出乎意料的成功。世界各地的开发工程师、运维工程师,还有各种IT管理人员、工具爱好者齐聚一堂分享相关技术和实践。从此之后,DevOps在全球开始流行起来。近几年随着微服务和Docker的流行,DevOps得到大规模的应用和实践。
- 敏捷开发和DevOps并不是孤立或对立的关系,其实敏捷是DevOps中的关键组成部分。一般而言,敏捷开发关注于开发过程中的实践,而DevOps包含从开发、持续测试、持续部署到运维的整个过程。
1.3、DevOps生命周期和循环
1.3.1、DevOps的生命周期
-
- 可以更好地帮助我们理解它们在软件开发过程中所处的环节。
- 敏捷开发包含了从规划(涉及需求分析和设计)、代码开发到构建的过程。
- 持续集成CI(Continuous Integration)在敏捷开发的基础上包含了持续构建和测试的过程;持续集成加强了对开发人员的反馈过程,快速验证并解决问题,提升开发效率。
- 持续交付CD(Continuous Delivery)在持续集成的基础上,增加了版本交付的过程;持续交付加强了和测试人员的交互过程,每天都有可用的版本,避免测试阻塞,提升测试效率。
- DevOps在持续交付的基础上,包含了部署和运维反馈的过程;DevOps加强了用户体验,用户所使用的环境每天迭代更新,用户反馈的问题短时间得到更新,用户体验得到持续提升。
1.3.1、DevOps循环
- 经典的DevOps循环如图1-2所示。
- 这个循环包含了开发和运维两部分工作,通过自动化的测试和部署把这两方面的工作进行集成。
- 一份关于敏捷开发和自动化测试的报告显示,有70%的团队采用了敏捷开发,但只有30%的团队采用了CI,至于CD就更少了。
1.4、DevOps价值
- DevOps可以缩短软件发布周期,提升软件质量、安全以及反馈速度。从2016至2017年的DevOps现状调查变化中可以看到,2017年DevOps进一步提升的目标不再是生产效率,而是质量和稳定性。
- DevOps价值有如下:
- 文化:DevOps首先是一种团队文化的转变,团队拥有共同的目标和信仰。
- 沟通协作:沟通在团队工作中非常重要,团队可以通过一些实时工具进行协作,通过持续沟通,团队的任务对所有成员可见,团队成员掌握了最新进展,可以有效进行技能传递,消除由于沟通、依赖导致的无效等待,改进团队全方面的能力,包括设计、开发和监控。
- 信任:是团队的最大特质,没有对团队成员的信任,团队不可能获得成功;成员之间在沟通、协作的过程中增强了相互之间的信任,同时也增强了团队凝聚力,提升了工作质量。
- 减少对专家的依赖:此前大部分组织都是领域专家领导的面向功能的开发团队,比如开发部、质量部、网络管理部、数据库管理部等。DevOps通过取消这些特性团队来减少对专家的依赖;团队的每个成员都是通才,可以解决团队面临的各方面的问题。
- 系统性思考:以业务逻辑的视角来全面理解系统所实现的功能,而不只是局限于深人理解某个领域。
- 精益生产:为组织的纪律、效率和有效性设置标杆;在此过程中努力做到消除浪费、加强质量、延迟承诺、快速发布、尊重个人和全局优化。
- 自动化:所有需要重复的工作都努力做到自动化、代码化,经验可复制、可推广。
- 持续改进:创建一个持续改进的文化氛围,无论是困难还是收获都进行分享,努力打造学习型团队,最终得以持续改善日常工作。
2、DevOps与团队文化
- DevOps团队在内部共享态度、价值、目标和实践,而这些团队通常具有如下特质:
- 团队每个成员都有极大的自主权,可以选择愿意承担的工作、任务和挑战;充分授权让团队成员拥有极大的自信,同时也能够得到快速锻炼。
- 团队成员共担责任,对于错误或失败每个人都有责任,是团队整体的错误,而不归责于某个成员。
- 团队成员在接受不同任务的过程中,可以更全面地了解团队承担的职责,对于团队成员实现的功能也增加了认识和理解,在此过程中,进一步锻炼了自己的能力,可以参与各种角色和功能开发。
- 团队成员分享快乐和痛苦,一同解决技术问题、跨越障碍,收获成功和喜悦,并共同分担在此过程中的痛苦和磨炼。
- 团队成员在解决困难、分担和分享的过程中学会担当,因而,每个成员都会积极处理团队需要承担的事务和需要解决的问题,进一步提升团队的主动性和自治性。
- 如果认为使用自动化的工具把开发和运维工作结合在一起就达到了DevOps,或者某个特定的团队来实施DevOps,其他团队保持传统的开发模式,其实就是打着DevOps旗号的伪实践,DevOps的价值和文化很难在这种模式下表现出来并发挥作用。DevOps是一种文化的转变,团队成员同时负责了开发、部署和运维的工作。在开发过程中不考虑如何部署,不考虑如何运维,仍然是割裂的团队和工作模式。
- 在向DevOps团队转型的过程中,可以把团队分为三个等级:
- 变更前置时间指的是从代码提交到代码在生产环境中成功运行之间的时间。
- 让我们看一下高效能团队和低效能团队在表现上的差异:
- 高效能团队的部署频率是低效能团队的46倍。
- 高效能团队部署变更到生产环境的效率比低效能团队快440倍。
- 高效能团队部署故障恢复时间比低效能团队快96倍。
- 低效能团队部署变更失败率比高效能团队高5倍。
- 高效能团队人工参与的时间相当于低效能团队的60%~70%。
- 高效能团队倾向于使用主干分支,每天向主干分支合入,分支只存在若干小时,而低效能团队则采用长时间的特性分支。
- 高效能团队更倾向于使用松藕合架构,无论是团队独立开发的应用和服务,还是必须与其他团队合作开发需要交互的服务。
3、DevOps工具链
1
# #标签:软件开发,运维,DevOps01,DevOps,开发,敏捷,团队,什么 From: https://www.cnblogs.com/maiblogs/p/17188892.html