上文传送门
juejin.cn/post/714954… DevOps的探索（篇一）
DevOps登场
上文我们提到，敏捷开发仅是打通了开发和测试人员的围墙，提升产品的软件开发的效率和版本更新的速度。但是开发和运维的隔阂和围墙却仍旧存在。于是，打破开发和运维之间围墙的破墙工具，也就是我们的主角--DevOps登场。
团队要根据DevOps思想重新梳理全流程的规范和标准。在DevOps的流程下，运维人员会在项目开发期间就介入到开发过程中，了解开发人员使用的系统架构和技术路线，从而制定适当的运维方案。而开发人员也会在运维的初期参与到系统部署中，并提供系统部署的优化建议。
大家是否还记得在上文的敏捷开发中我生动的用生产一辆汽车来比喻敏捷开发，那么根据生产汽车的例子，我们进而来生动的理解一下DevOps，它就是我们在生产到自行车或者电动车的时候，不只只是测试通过，该车可以供客户骑行，还要做出交付文档，完成给用户部署，在逐个阶段，不单需要开发和测试，还需要运维团队。这样就在敏捷开发的基础上，更加完善流程。让客户随时提前需要使用产品或者更改功能时，都能清楚的真实的使用到产品。可能大家会有疑惑，这是为什么呢？就是因为在逐步逐层级实现功能的各个阶段，运维团队都能针对当前的发布版本与开发环境对应部署与监控问题。当然这样也能更小的规避风险，毕竟开发环境和生产环境相比还是会有系统，版本，网络等不确定因素的差异。
如何实现？（重点）
至此，相信大家都能更通俗地了解DevOps，我们再回顾下wiki对DevOps的定义，DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。我们已经知道了DevOps需要开发，测试，运维等团队紧密沟通交融迭代开发产品，那么，有一个问题请大家思考下，我们真的只是要把开发团队，测试团队，运维团队沟通在一起吗？每天定时一起把产品对应的团队人员叫在一起开会？把工位挨在一起？如何沟通？怎样沟通？怎样真正意义上的高效沟通？人工手动把开发好的功能打包编译发给测试点点点测试用例发给运维开起来容器开起来服务器一步一步搭建？我们不妨在此稍加思考，再带着这些问题和作者一起深入探索。
CI
我们来考虑一个问题，在开发完一个小功能模块时，需要测试时，我们如何保证每个人负责开发的功能点的代码都push到git仓库，在内部群聊中@所有人问是否有人代码还未提交，还是在大喊一声谁还没有提交代码。等大家都提交之后，每个人在pull最新的代码本地跑起来自验一遍，然后再去联系测试把这个模块测试一遍。当出现问题和bug时，再花时间来分配寻找是谁开发出来的bug，更难受的是，一个同事开发的部分没问题，可其他人开发的影响到这个同事的代码，再去花时间沟通排查问题。解决掉之后，再去交给测试重新测试之前未通过的问题，然后发现，刚才未通过的通过了，刚才通过的却有缺陷了。相信读到这里的你已经严重的意识到问题所在了，这样的流程，除了让人头疼就是浪费时间，甚至会影响团队和谐。那么，如何解决呢？我们来介绍一下CI。
CI是什么？为什么写在这里？CI 的英文名称是 Continuous Integration，中文翻译为持续集成。CI 中，开发人员将会频繁地向主干提交代码，这些新提交的代码在最终合并到主干前，需要经过自动化编译和自动化测试流进行验证。解释到这，大家是否觉得，CI不恰恰可以解决刚才提到的各个问题吗。是的，开发工程师在开发完成代码后自验通过后直接push代码到git仓库中，就一切都不需要再管了（除非出现bug需要修复）。我们先不考虑通过什么工具来实现这些自动化功能，我们现在关注这个流程。在提交代码后，持续集成服务器会自动进行构建编译后，测试会把对应模块的测试用例的自动化测试脚本同步，当自动化单元测试通过后，开发工程师提交的代码才能成功提交到git仓库。CI是需要对开发人员每次的代码提交进行构建测试验证。确定每次提交的代码都是可以正常编译测试通过的，测试团队也可以在开发团队开发中同步编写自动化测试脚本后放入开发环境服务器中。CI就是让我们的构建编译测试融入我们日常的开发中。
CD
CI我们了解了之后，什么又是CD呢？CD 对应两个英文名称，持续交付 Continuous Delivery 和持续部署 Continuous Deployment。持续交付是持续集成的延伸，将集成后的代码部署到生产环境，确保每次持续集成后的代码可以成功无问题的部署到生产环境中并且投入使用，更可以以可持续的方式快速向客户发布新的更改。持续交付意味着所有的变更都可以被部署到生产环境中，持续部署意味着所有的变更都会被自动部署到生产环境中，但是出于业务考虑可以选择不部署；如果要实施持续部署，必须先实施持续交付；持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署；持续交付表示的是一种能力，而持续部署表示的则一种方式。持续部署是持续交付的最高阶段。
它的优势就是整个团队可以在很短的迭代内交付产品，确保可以随时的可靠的发布新版本，发布的时候可以进行手动的发布。我们可以想象一下，产品不用在每个大版本开发完成后上线，而是在每个小功能或模块开发完成后就可以上线。客户随时都可以得到产品项目的进展的版本，我们仍拿生产汽车来举例，在持续交付持续部署下，客户无需等整辆车生产好之后，再进行驾驶并且提出问题和更改，而是可以在自行车生产好时就进行使用并发现问题及时反馈给产品团队，随后自行车又被改造成电动车，再交给客户进行沟通，一步一步最终完成客户要的汽车，因为持续交付持续部署，客户每一阶段都完整的参与进来，感知产品的每一步，所以此时的汽车，一定是客户最期望的汽车。更生动的举例，如果你在面馆参与一碗面的制作中，你会及时沟通提出你的忌口和你的口味喜好，那么最终我们得到的这碗面，一定是我们最喜欢的。
CI/CD与DevOps的关系
DevOps是CI、CD思想的延伸，CI、CD是DevOps的基础核心，如果没有CI、CD自动化的工具和流程，我们谈DevOps，也只是空谈无法落地。DevOps讲求的把开发工程师，测试工程师，运维工程师沟通于一起，实现的关键也是CI/CD。
相信读到这里，我们对DevOps的实现会有更深刻的体会。下篇我们会介绍DevOps的核心CI/CD又是通过何种工具如何实现。
