持续交付流水线

本文是对本人对devops持续交付流水线的一些个人理解（只针对现所在公司的情况），不一定准确，仅供参考，后期会不定期修改

一、任何公司项目都存在流水线

一些初创公司有可能就寥寥数人，老板可能就兼任产品经理，开发可能兼任开发、测试、运维、、

即便这样的情况，我也说项目从提出到面向用户也是存在流水线的

都会经历：需求提出-->开发-->测试-->上线

这可以说是最简单的一个流水线了，每个节点都是人工手动完成，还可能是同一个人完成，可能没有人给出什么时间点干什么事，但具体的流程架子是抹不掉的

到这里我们来抛出个问题：在这样的公司去试行devops现实吗？有必要吗？

二、CI、CD

CI：持续集成，传统的项目会将项目拆分为几个大的模块，然后各自开发，开发完后（这个时间相对较长）各个模块开始集成（拼凑），然后发现很多地方格格不入，难度很大

而持续集成则是，开发人员修改很小一部分代码就立马提交到代码仓库进行集成，这样整个项目到结束一直在不断做集成，风险相对较小

CD：持续交付，以前我们在开发测试完毕后会手动搭建服务器环境，然后手动部署对外开放，后面我们修改代码后又会重复去打包代码，上传服务器、重启，这一切的操作都是手动完成，这中间很明显有很多的不足：环境的不一致、手工的失误、异常回滚等等，，需要耗大量的人力；

而持续交付是：代码提交后自动触发后续的打包、部署、异常回滚等，大大减少耗时和错误率，让整个流程更自动化（也就是释放双手）一个按钮就可以实现上线

三、理想中的持续交付流水线

持续交付的过程中大多数情况下开发并不是瓶颈，出现瓶颈的地方往往是测试、环境、上线、异常回滚；

而理想中的情况就是减少人工测试，测试完毕一键上线，系统随流量自动扩缩容、、、

自适应，，解放劳动力

四、何时引入devops

引入devops的目的就是为了解决整个交付过程中惹人烦的地方，接入之前首先要对项目的整体架构，整体流程有全局概念，然后找出实际痛点，有针对性的解决，devops并不是重置流程，而是针对痛点贯穿流程

如果是新项目：可将开箱可用的开源项目引入进来如jira、Jenkins、gitlab等能大大提高效率

如果是老项目：我们要尽可能的从全局出发，找到痛点，有针对性的引入开源工具解决问题

这是一个持续的过程，一切为了效率，当然我们还可以自研更适合公司模式的工具，让人性化和效率结合，

经过一系列的优化后肯定会到达一个适应期，就是表面看似没问题；那么我们就要主动发现问题，要制定一系列的指标，通过指标来判断哪些地方是瓶颈，有问题才能更好的解决问题

 

公众号主要记录各种源码、面试题、微服务技术栈，帮忙关注一波，非常感谢