8.分布式服务架构:原理、设计与实战 --- 敏捷开发2.0的自动化工具

第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容器化工具

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
分布式服务架构:原理设计实战pdf》是一本介绍分布式服务架构的书籍,以下是我对这本书的回答。 这本书是关于分布式服务架构原理设计实战的指南。分布式服务架构是一种软件架构模式,它通过将一个应用程序分解为多个独立的服务来处理不同的业务逻辑。每个服务都可以独立部署、扩展和管理,通过网络进行通信和协作。 在这本书中,作者首先介绍了分布式服务架构的基本原理和概念。他们解释了为什么分布式服务架构在现代软件开发中如此重要,以及如何将其与传统的单体应用程序架构进行对比。接着,他们详细讨论了设计分布式服务架构的一些关键问题,如服务的边界划分、通信机制、数据一致性和容错机制等。同时,他们还介绍了一些常用的分布式服务框架和工具,如Dubbo、Spring Cloud和Kubernetes等。 在实战部分,作者提供了一些实际案例和应用场景,展示了如何应用分布式服务架构来解决现实世界中的问题。他们从不同的角度和维度分析了这些案例,包括性能优化、系统可用性、弹性伸缩和容灾等。通过这些案例,读者可以更好地理解和应用分布式服务架构。 总的来说,这本书在分布式服务架构原理设计实战方面提供了全面的指导。无论是对于初学者还是有一定经验的开发人员来说,这本书都是一个宝贵的参考资料。它不仅介绍了基本原理和关键概念,还提供了一些实际的案例和经验教训。通过阅读这本书,读者可以更好地理解和应用分布式服务架构,从而提高软件开发的效率和质量。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值