第8章 敏捷开发2.0的自动化工具
8.1 什么是敏捷开发2.0
8.1.1 常用的4种开发模式
1.瀑布式开发
2.迭代式开发
3.螺旋式开发
4.敏捷开发
8.1.2 什么是DevOps
devops 的开发流程如下:
1.提交:工程师将持续在本地测试后,提交到版本控制系统如git
2.编译:持续整合系统(如jenkins CI),在检测到版本更新时,便自动从git仓库拉去最新的程序,进行编译,构建
3.单元测试:jenkins 完成构建后,会自动执行指定的单元测试代码
4.部署到测试环境中:在完成单元测试后,jenkins 可将程序部署到与生产环境相似的测试环境中进行测试
5.预生产测试:在预生产测试环境中,可以进行一些最后的自动化测试,例如Selenium测试及实际情况类似的测试,可由开发人员或者客户手动进行
6.部署到生产环境:经过所有的测试后,便可将最新的版本部署到实际生产环境中
8.1.3 敏捷开发2.0解决的问题
1.持续集成
是一种软件开发实践,要求团队成员经常集成其工作,每个人至少每天集成一次会导致每天有多个集成。集成是通过自动化的构建进行验证的,这些
构建运行回归测试,以尽快检测集成中的错误。团队慢慢发现,这种方法有利于集成问题的大幅减少,更快的实现有凝聚力的软件开发方式。
2.持续交付
是在持续集成的基础上,将集成后的代码部署到更贴近真实的运行环境的预生产环境中。比如,我们完成单元测试后,可以把代码部署到连接数据库的
staging 环境中进行测试。如果代码没有问题,则可以继续部署到生产环境中。
3.持续部署
是持续交付的更高级阶段,即所有通过了自动化测试的改动都自动部署到生产环境中。大多数公司如果没有受到制度的约束或者其他条件的影响,则都应该
以持续部署为目标。在很多业务场景里,一种业务需要等待其他功能完成了才能上线,这使得持续部署不可能实现。虽然可以使用功能转换解决很多这样的问题,
但是并不是每次都会这样。所以,持续部署是否适合某个公司是基于该公司的业务需求的,而不是技术限制。
为了实现敏捷开发2.0,我们需要采用持续部署,微服务和容器这三种技术方案:
1.持续部署:能够持续自动反馈应用程序的提交状态,减少错误等;同时为产品的交付提供了质量保证,能够快速投入市场
2.微服务:使技术选型,架构系统更自由;开发更快速,周期更短,服务更容易扩展
3.容器:使部署成百上千的微服务更加容易,系统更加稳定
8.2 敏捷开发的自动化流程
8.2.1 持续集成
1.向代码库中提交代码
开发者在功能分支上独立的开发新功能,并合并到主干上。持续集成工具能够检测代码仓库,一旦有用户提交代码,新代码就会被检出,并运行pipeline流程。
pipeline 由一组并行的任务组成,这些任务中若有一项出错,则整个pipeline便会出错并停止运行。并通知给代码提交者。pipeline 全部执行通过后,会进入
下一个阶段,通常是提交SQ进入人工测试阶段。
开发者 => 代码仓库 => 持续集成工具 => 持续集成pipeline => QA人工测试
2.静态代码分析
静态代码分析是在不运行代码的情况下,通过词法分析,语法分析,控制流,数据流分析等技术对代码进行扫描,验证代码是否满足规范性,安全性,可靠性,
可维护性等指标的一种代码分析技术。
如Java语言一般使用 CheckStyle 和 FindBugs,而针对JavaScript 一般使用JSLint 和 JSHunt。像PMD 这样的工具对很多语言都适用。
3.部署前的单元测试
部署前的测试是必须的,不像静态分析是可选的,它是不需要部署代码就能直接运行的测试,例如单元测试。也可以是不需要部署的功能测试。
集成测试工具 => 静态代码分析 => 部署前的测试
4.打包部署到测试环境
集成测试工具 => 静态代码分析 => 部署前的测试 => 打包 => 部署测试服务器提交QA
5.预生产环境测试
这个阶段主要包括功能测试,集成测试和性能测试。如果预生产环境的测试全部通过,那么整个持续集成的流程就完成了,接下来就到持续交付和持续部署阶段了。
8.2.2 持续交付和持续部署
持续交付的流程和持续集成的流程大同小异,最大的区别在于整个流程执行完成后其结果的认可度:持续集成只要求最终校验通过,持续交付则要求完美的实现所有的
预期,随时准备部署上线。当然最终能够上线大多数情况取决于公司的政策决定。持续交付还有一个不同的点在于,它在通过了全部的流程后,不再需要人工测试阶段,因为
持续交付技术本身能够最大程度的保证所以编译结果都是正确的。
开发者 => 代码仓库 => 持续集成工具 => 持续交付pipeline => pipeline 全部通过 => 达到上线标准
持续部署是比持续交付更高级的阶段,能够全自动的把每一次通过编译测试的代码直接部署到生产环境中,是一整套的自动化过程。在这种模式下,我们需要进行两次
不同的测试:预生产环境测试和生产环境测试,比如,在QA测试服上我们需要执行所有的测试,而部署到预生产只需要执行集成测试,最后进行生产测试。而最终应用程序
是回滚还是面向公众发布,取决于最后一次的生产环境测试的效果,一旦有问题就回滚。当然,如果我们使用了代理服务,就不需要回滚了,因为在用户真正看见新的更新
时,我们早已察觉并解决了问题。
持续集成工具 => 静态代码分析 => 部署前的测试 => 打包 => 部署测试服提交QA => 预生产测试 => 发布生产环境 => 生产测试 => 代理
8.3 敏捷开发的常用自动化工具
8.3.1 分布式版本控制工具Git
8.3.2 持续集成和持续交付工具Jenkins
8.3.3 基础平台管理工具SaltStack
8.3.4 Docker容器化工具