软件开发、持续集成（CI）、持续交付(CD)、持续部署（CD） 和 版本管理(Version Control) 的理解和思考

PS：要转载请注明出处，本人版权所有。

PS: 这个只是基于《我自己》的理解，

如果和你的原则及想法相冲突，请谅解，勿喷。

前置说明

  本文作为本人csdn blog的主站的备份。（BlogID=090）

  本文发布于 2019-12-20 16:52:54，现用MarkDown+图床做备份更新。blog原图已丢失，使用csdn所存的图进行更新。（BlogID=090）

环境说明

  无

前言

---

  软件开发，水很深。

  做了两年有余的攻城狮，做了代码开发，技术框架搭建，环境搭建，项目管理，用户沟通等工作，我从代码开发者的角度来看，我们的写的内容到用户实际使用往往中间有许多的内容的，作为开发者，千万别人为自己写的代码就是整个项目周期的全部，其实code部分只占很少的时间，从code后到交付给用户使用的中间部分才是非常大的一个时间占比。

软件开发思考

---

  在学校里面，当我们学习软件工程这门课时，教授的内容是比较传统的软件开发流程，它们大概是如下的流程：

1. 获取到大致项目需求
2. 需求评估
3. 需求文档整理
4. 概要设计（技术框架设计）
5. 编码
6. 测试
7. 交付

  当交付给用户后，实际情况是不可能一次性交付成功的，都会涉及到相关的需求细化和变更，于是又要重复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: 有问题请留言，看到后我会第一时间回复。