PS:要转载请注明出处,本人版权所有。
PS: 这个只是基于《我自己》的理解,
如果和你的原则及想法相冲突,请谅解,勿喷。
前置说明
本文作为本人csdn blog的主站的备份。(BlogID=090)
本文发布于 2019-12-20 16:52:54,现用MarkDown+图床做备份更新。blog原图已丢失,使用csdn所存的图进行更新。(BlogID=090)
环境说明
无
前言
软件开发,水很深。
做了两年有余的攻城狮,做了代码开发,技术框架搭建,环境搭建,项目管理,用户沟通等工作,我从代码开发者的角度来看,我们的写的内容到用户实际使用往往中间有许多的内容的,作为开发者,千万别人为自己写的代码就是整个项目周期的全部,其实code部分只占很少的时间,从code后到交付给用户使用的中间部分才是非常大的一个时间占比。
软件开发思考
在学校里面,当我们学习软件工程这门课时,教授的内容是比较传统的软件开发流程,它们大概是如下的流程:
- 获取到大致项目需求
- 需求评估
- 需求文档整理
- 概要设计(技术框架设计)
- 编码
- 测试
- 交付
当交付给用户后,实际情况是不可能一次性交付成功的,都会涉及到相关的需求细化和变更,于是又要重复5-7的步骤。
到了实际工作中后,会出现一种现象,项目交付的时间尽可能短,项目需求变更和交付时间也需要尽可能的短,于是就出现了传统按部就班的开发模式不能够完成相关的项目,于是出现了一些快速开发的方法,如敏捷开发。
在实际过程中,敏捷开发只是加速开发迭代部分,如果没有控制好,就会出现开发速度加快了,但是测试,交付会出现问题,为啥会出现呢?其实很简单,就是都是独立串行的,这会导致从整体看,项目开发时间拖长。
为了解决类似的问题,又提出了类似Devops的说法,就是大家都坐一起,相互依赖的做事,因为都是站在整体考虑的,所以可以对整个流程(开发、测试、交付)的情况进行协调,效率会比较好。
为了把上述的问题处理好,我们必须要引入一些工具(VCS,CI,CD,CD)来帮助我们做事,否则是处理不好的这些事的,就会出现:要不效率低,能完成。要不效率高,就是容易出错。
版本管理系统(Version Control System)
版本管理系统,这个不用介绍了,大家平常工作中都会用,常用的有svn和git,如果没有接触过,有兴趣的可以多去网上找找资料学习学习,它们可以提供代码管理、溯源等功能。
版本管理系统除了本身的属性外,它自身带的一些特性可以用来做一些其他的事情,比如它的push事件可以用来触发一些其他的工作。
持续集成(Continuous Integration)
持续集成其实对于开发者来说,是很简单的一件事情。就相当于你code完,然后手动编译,测试这样的一个流程。平常比如你用vs写了一个程序,然后你右键编译,然后f5运行测试,最后到相应的目录去打包发布程序。这种方式在软件规模比较小的时候,完全可以采用,流程可控的,当软件规模过大,而且需要持续维护修改时,这种方式会让人炸裂的。
所以持续集成简单的归纳为通过一些工具来自动化编译,单元测试,并生成相关的报告。至于什么时候自动开始编译,这里就是上文说的VCS的相关事件来触发就行。
持续交付(Continuous Delivery)
持续交付其实由相关QA质量保证团队来手动或者自动的方式,检测刚刚持续集成的程序版本,在模拟生产环境下,是否能够正常工作。
这里强调的还是内部测试,只是相关测试更贴近于实际生产环境。注意这里没有部署到生产环境。对于很多公司来说,其实QA软件部门是等于没有的。
持续部署(Continuous Deployment)
持续部署就是通过一些工具,自动化的把经过单元测试,QA测试后,打包,自动化部署到生产环境这么一个过程。
关于ci,cd,cd,vcs的说明
其实就以上而言,你可以直接认为就是,使用工具,自动化从vcs拉取代码,自动化编译测试程序,(半)自动化QA保证,自动化部署程序到生产环境这么一个过程。这里借助了很多自动化工具,大大节约了程序多次迭代的时间。所以对于软件开发来说,哪怕是敏捷开发,devops等模式都可以很好的建立起来。
但是不是说以上的就是最好的呢?因为在软件第一次发布的时候,如果借用以上的自动化流程,需要一个人或者团队来建立这个自动化逻辑,这是比较烦的一件事情,所以如果软件迭代次数少,规模不大,不要硬搬硬套上述整个流程,实在是不合适。但是里面的vcs,我还是希望每个项目都能够用起来,真的很不错。
Jenkins , Travis ,Github Action 等ci,cd工具说明
这些工具是我用过的,世界上还有许多这样的工具,看个人喜好了。这里要对这些工具分一个类,按照他们的部署位置分一下,一种是需要自己搭建相关服务的,并完成cicd的事情,一种是自己提供相关配置文件(yml),由云端给你解析这个配置文件并完成相关功能。
这里Jenkins是属于需要自己搭建服务的,需要自己定义相关的流程并完成cicd的事情。
Travis,GitHub Action这种是输入云端的功能,基本上算是属于SaaS,你只需要提供遵循相关语法的配置文件,它们就会自动完成你定义的流程。
后记
总结
合适的事情,选择合适的工具。不是所有的情况都能够把上面的整套给怼到团队中去,但是整个软件开发的流程和内容还是值得我们大家思考和借鉴的。
比如我们的团队就引入了git和jenkins就够了,能够做简单的版本管理和基本的软件集成测试。其他的手动介入性价比比较好。
比如我自己封装的一些开源小功能,我引入git,travis, github action就已经足够了。
参考文献
- 无
PS: 请尊重原创,不喜勿喷。
PS: 要转载请注明出处,本人版权所有。
PS: 有问题请留言,看到后我会第一时间回复。