由来
记得7月份刚刚换工作的时候，中午和老大一起去吃饭，回来的路上老大问我：“南橘，CI/CD有没有研究过？”
我隐隐约约在哪里听过这个名词，但是又想不起来，秉着实事求是的态度，我斩钉截铁的说：“老大，我不知道CI/CD是个啥。”
老大当即对诚实的我进行了一顿夸耀，并且高兴地奖励我回去研究CI/CD的机会，并且告诉我，我们team的ScrumMaster马上要入职了，加下来的工作会采取持续集成(CI)和持续交付( 持续部署)(CD) 的模式。
没过几天，新的ScrumMaster(就叫他S哥)就来了，项目也准备开始了。经过前期对需求的反复熟悉，我一下子就新建了好几个工程文件，正准备摩拳擦掌展露自己的实力的时候，S哥赶紧拦住了我：“不急，我们先玩一个游戏”。
接下来，S哥组织了整个Team成员对水果从口感、大小、外形、方便程度等各个方面进行打分，并且只要有人的分数与平均分不一致，就需要阐述自己的理由。这个方法很棒，一边让我们知道了各个同事的口味，一边也让我们理解了实现CI/CD中的重要前提：任务拆分。
任务拆分
举个例子，在进行CI/CD的过程中，有一项任务是每天的例会（Daily meetings.）。大家快速交代自己昨天任务的完成情况，如果有问题，就在这里提出来，寻找相应的支持或者共同探讨。一方面可以提高工作的效率，另一方面也大大减少了划水摸鱼的情况。而要实现每天都有能分享的东西而不是发表一些类似于“昨天写代码，今天写代码，明天还是写代码”的发言，任务拆分就非常重要了。
在一个API的前期开发中，大体上可以分为：
- 1、项目git搭建
- 2、技术文档编写
- 3、代码编写
- 4、测试用例编写
- 5、unitTest
- 6、Sit环境搭建
- 7、代码review
- 8、jenkins自动集成环境搭建
- 9、AC校验
- 10、上下游联调
- 11、auto测试搭建
- 12、集成校验搭建
- ...
当然，真正开发的时候可划分的任务会更加细致与更加贴近业务。
这个时候，之前玩游戏建立起的默契就可以放在这里对任务进行打分了。比如，我们统一以“项目git搭建”为基准点1分，以“代码review”为基准点8分，高于8分的任务继续拆分，比如代码编写这个环节大家给出了13分，那么按照斐波那契额数列的就需要拆分成5分和8分两个任务，并分配给相应的开发人员进行开发。
至此，将一个周期内所有需要进行的工作拆分成不同分值的任务，再根据前几个周期的完成情况合理的规划未来每个周期可以完成的任务。这样，通过任务拆分，对于项目组的开发能力就有了一个合理的评判标准，不会因为任务过多导致加班加点，也不会因为任务太轻导致疯狂摸鱼，并且为更好更快的发布产品，实现敏捷开发打下了基础。
敏捷开发
CI/CD就是实现敏捷开发的一种方式
什么是敏捷开发？我们都知道，互联网行业卷，互联网行业快，今天出需求，明天就上线是一种常态，而敏捷开发就是推动这个常态形成的助力。
敏捷开发的核心就是拥抱变化与快速迭代。
敏捷开发并不追求前期完美的设计、完美编码，而是力求在很短的周期内开发出产品的核心功能，尽早发布出可用的版本。然后在后续的生产周期内，按照新需求不断迭代升级，完善产品。
用一个广为流传的图片来体现敏捷开发和传统开发模式的区别：
那我们知道了什么是敏捷开发，也就知道CI/CD的方向是什么了。
CI/CD
编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署
通过这张图，我们可以看到三者拥有不同的自动化交付周期。
那么，所谓的持续集成和持续交付（持续部署） 究竟是什么呢？
持续集成是一种软件开发实践，目的是希望团队中的成员频繁地将代码合并到代码仓库的主干分支上，并且一旦代码成功合并，系统就会通过自动构建应用并运行不同级别的自动化测试来验证这些更改，从而更早更快地将问题暴露出来。将传统开发模式中经常会出现一堆bug的代码集成阶段分散在每个工作日中，有效地降低了bug修复的难度和时间。
持续交付是持续集成的延伸，将集成后的代码部署到指定环境仓库之中(一个可随时部署到生产环境的代码库)，并且经过一系列的自动化流程。在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中。
持续交付经常容易与持续部署混淆。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中。持续部署是持续交付的最高阶段。
CI/CD提供了一个优秀的 DevOps 环境，对于整个团队来说，好处与挑战并行。无论如何，频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。而我们，作为未来的一部分，也要积极地学习新的技术与开发模式，积极地拥抱未来。
有需要的同学可以加我的公众号，以后的最新的文章第一时间都在里面，也可以找我要思维导图
