无论是瀑布式开发、敏捷开发还是DevOps,整个流程都分为设计、开发、测试和部署四个部分,只不过各个部分的开始和结束时间节点不同而已!下图很好地解释了这一点。
从瀑布式开发到敏捷开发再到DevOps,各个阶段的切换速度越来越快,瀑布式开发和敏捷开发的运维部署工作都是放到最后,而 DevOps 结合敏捷开发思想,将部署工作也敏捷起来。
瀑布式开发是早期被广泛采用的软件开发模型,要求有明确的需求,按照需求一步步做好规划,每一阶段工作的完成是下一阶段工作开始的前提,每一阶段都要进行严格的评审,保证各阶段的工作做得足够好时才允许进入下一阶段,它适用于需求明确的项目。
最大的风险是,当产品研发完成后, 到了产品测试阶段如果发现了问题 ,或者发现其无法满足市场需求, 那么就需要重新开发,甚至需要重新规划产品。
敏捷开发是一种以用户需求进化为核心、迭代、循序渐进的开发方法。首先把用户最关注的软件原型做出来并交付给用户,用户在实际场景中发现问题并给予反馈,研发人员快速修改弥补需求中的不足。上述过程不断迭代,直到用户满意。
敏捷适用于需求不明确、创新性或者需要抢占市场的项目,特别适合互联网项目。
1、敏捷宣言定义了 12条原则
2、敏捷的核心价值观
DevOps是一种软件开发实践,它将人员、流程和技术结合在一起,以交付持续的价值。该方法分为计划和跟踪、开发、生成和测试、交付以及监视和操作。
DevOps 的独特之处在于开发、IT 运营、质量工程和安全团队协同工作,在发布新产品、版本或更新所涉及的所有任务中创造效率。
DevOps将开发和运营合并为一个团队,专注于快速交付和稳定的基础架构。其目标包括:
DevOps 是一种文化,是一种思维状态,是一种软件开发的方式或者基础设施的方式,也是一种构建和部署软件和应用的方式。它假设开发和运维之间没有隔阂,他们一起合作,没有矛盾。
DevOps 基于其它两个领域的实践: 精益和敏捷。DevOps 不是一个公司内的岗位或角色;它是一个组织或团队对持续交付、持续部署和持续集成的坚持不懈的追求。三种方式定义 DevOps 的理念:
1、DevOps持续交付的八大原则
DevOps持续交付的八大原则对可运维性给出了这样的定义,在企业中研发和运维体系必然需要相互配合,开发团队负责功能性需求实现的同时,在架构和编码上注重非功能性需求的实现,测试团队与运维团队将围绕着各自职能的需求,规划与建设DevOps流水线中对应的工具系统,加速企业IT价值链的流转,以为企业创造更大的商业价值。
2、DevOps提倡的原则
从瓶颈点着手
Start Small,从小做起
痛苦的事情优先解决
工具也是一种文化
自动化别人,先自动化自己
价值拉动,而非事务驱动
构建指标,驱动DevOps落地。
创建从开发过程下游至上游的反馈环。
强调全局优化,避免局部优化。
持续做试验和学习的文化,通过反复实践来达到精通。
DevOps实践涉及到开发部门以及软件研发的整个生命周期,这意味着在整个开发生命周期中,涉及到一大批新旧工具,包括从规划、编码、测试、发布、监控等自动化的流程工具
Cloud Native Landscape
DevOps融合了一系列基本原则和实践的方法论,并从这些实践中派生出了各种工具。这些工具体现在软件开发和交付过程的不同阶段:
编码:代码开发和审阅,版本控制工具、代码合并工具
构建:持续集成工具、构建状态统计工具
测试:通过测试和结果确定绩效的工具
打包:成品仓库、应用程序部署前暂存
发布:变更管理、发布审批、发布自动化
配置:基础架构配置和部署,基础架构即代码工具
监控:应用程序性能监视、最终用户体验
1、能力一:DevOps不可或缺的自动化能力
主要体现在三点上:
自动化比手动快。
工具不会像人一样容易犯错误。
通过自动化按照定义执行确保每次执行的一致性。
2、 能力二:建立持续交付能力
主要体现在三点上:
通过统一的部署流水线将从代码提交到交付给用户的整个过程高度可视化出来,信息透明;让开发、测试和运维以高度一致的方式工作在同一个流水线上,真正建立起协作。
每一次的软件变更在这个完整的流水线中得到充分的验证,尽早发现有缺陷的变更。
将一些必不可少的控制环节內建到自动化过程中,比如质量保障过程、过程度量、过程审计信息等,从而弱化很多传统依靠人为检查的管理流程。
3、能力三:利益共同利的合作文化
以提高业务响应效率出发,要有一荣俱荣,精诚合作,共同进步的工作态度
DevOps 成功的关键在于文化转变,除了上面提到的工具,组织文化的转变也同等重要,我们总结出了很多 DevOps 的其他因素,比如人(People)的思想和思考方式、开发和运维的流程(Process)、精益(Lean)、自动化(Automation)、测量(Measurement。
在组织文化方面,DevOps 推崇:
尊重(Respect)
正视失败(Healthy attitude about failure)
不埋怨(Avoiding Blame)
精益求精
工程质量文化
快速验证文化
客户导向文化
DevOps是CI/CD思想的延伸,CI/CD则是DevOps的技术核心,如果没有CI/CD,没有自动化测试,DevOps是没有任何意义的。所以说DevOps是以CI/CD为基础来优化程序的开发、测试、运维等各个不同环节。
1、 CI:持续集成
持续集成是一种开发实践,它倡导团队成员需要频繁的集成他们的工作,每次集成都通过自动化构建(包括编译、构建、自动化测试)来验证,从而尽快地发现集成中的错误。让正在开发的软件始终处于可工作状态,让产品可以快速迭代,同时还能保持高质量。
2、CD
包含了两层内容:持续交付和持续部署。
持续交付:
持续交付是持续集成的延伸或者看作持续集成的下一步,它将集成后的代码部署到类生产环境,确保可以以可持续的方式快速向客户发布新的更改。如果代码没有问题,可以继续手工部署到生产环境中。它强调的是,不管怎么更新,软件是随时随地可以交付的。
持续部署:
持续部署是持续交付的下一步,在持续交付的基础上,由开发人员或运维人员自助式的定期向生产环境部署稳定的构建版本,持续部署的目标是代码在任何时刻都是可部署的,并可自动进入到生产环境。
持续交付是指团队确保每个变更可以部署至生产环境,但也许并不需要实际部署,这通常可能是出于业务方面的原因。而持续部署是指每个变更可以自动部署到生产环境。只有成功实现持续交付的前提下,才能进行持续部署。
好处 | 劣势 |
简单易用和理解 | 只有在最后一个阶段结束后,软件才会准备就绪 |
由于其刚性,管理简单:每个阶段都有明确的结果和流程审查 | 高风险和不确定性 |
发展阶段逐一进行 | 不是复杂和面向对象项目的最佳选择 |
适用于要求明确且不模棱两可的小型或中型项目 | 不适合长期项目 |
易于确定开发周期中的关键点 | 阶段的进展很难衡量,但仍处于发展阶段 |
易于分类和确定任务的优先级 | 集成在最后完成,不提供预先识别问题的选项 |
好处 | 劣势 |
功能需求的更正被实施到开发过程中以提供竞争力 | 由于永久性变化而无法衡量最终成本 |
项目按短而透明的迭代划分 | 团队应是高度专业和客户导向的 |
灵活的变更过程使风险最小化 | 新要求可能与现有架构冲突 |
快速发布第一个产品版本 | 通过所有更正和更改,项目可能会超出预期时间 |
好处 |
加强部门合作,实现更快地交付产品和服务 |
缩短产品上市时间,帮助企业更快地将新产品或服务推向市场 |
更新迭代时间更短,通过持续部署缩短升级周期 |
提升自动化能力,确保部署任务的可重复性,减少部署出错的可能性 |
减少资源浪费,通过精益运行和快速迭代更有效地利用资源 |
更快的反馈,帮助企业更好地处理不确定性 |
改变员工工作模式,确保所有相关人员理解变更的内容并全力合作 |
可扩展性,支持实时伸缩以解决冲突和摩擦 |
关于 DevOps 和敏捷,最重要的一点是它们不是互斥的。
DevOps 是一种文化,促进所有参与软件开发和维护的参与者之间的协作。
敏捷可以被描述为一种开发方法,旨在需求不断变化的现实中维护工作效率和驱动发布。
尽管 DevOps 和敏捷是不同的,但是如果将这两种方法结合使用,将会带来更高的效率和更可靠的结果。DevOps是敏捷的有效补充,是将运维纳入产品开发过程的思维方式,是敏捷开发方法论的升级,更强调自动化工具的实现与应用,以帮助实现软件的快速迭代。