DevOps 感想附CICD流程

1. 背景

做 DevOps 工作几年了，也感想颇多，多少个日日夜夜，从一个坑到另一个坑，不断的解决各种问题，也总结了不少方案，有了不少经验。

浅谈一下自己对 DevOps 和 CICD 的理解，不牵扯到具体技术，只是些想法分享一下。

2. CICD 流程

CI 持续集成，CD 持续交付/持续部署。

什么是持续集成，从源码到成品包的过程，你以为是直接打个包就完事了吗？不是那么简单，需要做的事还很多，不过也要控制速度，不然如何能称得上迅捷开发呢？

首先，开发人员将开发代码上传到公司私有仓库，gitlab 也好，svn 也罢，都可以。当然，也不能随意上传，需要建分支，建tag，每一次上传代码都要有依据，比如关联itsm等工单。不同环境需要不同的样式，比如开发环境使用分支，测试环境、预生产环境和生产环境使用 tag。还有，tag 名称也需要限制，不能随便起个名字就算了。

其次，开发人员或者测试人员在发布平台上创建工单，点击发布，此刻，发布平台会通过 webhook 将请求调度给 jenkins，加入到 jenkins 队列。等到 jenkins 有线程处理的时候，前提是已经搭建好 jenkins 集群，并且也创建编写好了相应的脚本和 pipeline 流水。会创建一个 pipeline ci 的流程记录，将 jenkins job id 回调给自动化发布平台。第一步，从 gitlab 上拉取对应服务对应分支 tag 到 jenkins 节点上。

接着， 调用 sonar 工具，进行单元测试和覆盖率测试，sonar 将测试结果传递给 sonarquebe 平台，sonarquebe 平台展示 sonar 扫描结果。此时，单元测试结果达到构建阈值要求时，进入流水线的下一步，否则暂停流水线并回调报错。

然后，节点选择本地构建工具，对源码包进行相应的构建操作。java/前端/go等源码分别选择相应的构建工具。构建结束后进入下一步。

接下来，进行成品包 dependcheck 测试，漏洞扫描达到发布要求了进入下一步。

最后，这里的最后，也只是 CI 流程的最后一步，上传到成品库，使用第三方如 jfrog 仓库也好，使用公司自建的 OSS 平台也行，需要根据环境区别存储，方便后期成品包查找。

以上 CI 的流程就结束了，还算是比较完整的，当然根据不同服务，需要走不同的流水线，每个流水线的 CI 步骤也不尽相同，有些需要跳过扫描等，所以，每一步要有个开关控制，方便管理调控。CD 流程呢，被称作持续交付，持续部署。顾名思义，你构建好的包，上线应用了才叫产品，放在本地只是一个包而已，接下来看看 CD 的流程。

首先，做免密。高可用多台目标服务器，你是否能连接上，如果连接不上，需要做免密配置。检验可以连接上，就跳过进行下一步。

然后，安装客户端工具。拉取成品包也需要客户端工具，对应的目标服务器上如果没有安装客户端工具如 jfrog，需要先安装 jfrog。

接下来，服务发布，不同类型的服务，初始化和启动方式不同，需要将脚本区别对待，使用 ansible-playbook 将 shell 脚本部署好后，执行 shell 脚本，开始服务发布。此处，如果不满足发布需求，比如某些依赖没有装，某些版本不配套，内存CPU不够用等，则报错停止流水线并回调错误。

然后，监控进程，看看进程是否启动完成，如果执行完脚本后没有进程，则报错回调错误。

接下来，查看发布日志，从日志中过滤关键词 error 等，如果存在，则提示发布人员错误，如无关紧要，则跳过继续发布。

最后，自动化测试，对上线项目进行自动化测试，没有问题，则整个 CICD 流程结束。

以上为 CICD 的整体流程，当然，同一服务，不同环境，所要求的 CICD 也不一样，要区分对待。

3. DevOps 感想

DevOps 是 开发运维结合体，俗称自动化开发运维，目的是将复杂的东西简单化，简单的东西自动化。将功能写进代码了，这里自己也总结了一些原则

隔离分治原则: 不同应用之间不能有太大耦合，尽量减少不同微服务之间的影响。

削峰填谷原则: 要考虑到波峰波谷，适量选择调度缓存，不能流量上来了就崩溃了。

功能单一原则: 微服务功能不能集成太大，不便于管理和维护。

使用限制原则: 又称权限控制，路由/资源等控制，不能无限制使用。

还有，所有的功能都不能脱离业务，不能你认为这个好你就开发，结果现状往往没有任何帮助，反而做了很多无用功。人员之间做好沟通，尽量有一个标准的开发规范让所有运开人员参考，不能人员一走，代码全换操作。

4. 总结

以上都是些个人工作中的应用与总结，写一写，理一理，不断去学习深入。这一行，学习是在原地踏步，要用尽去学，这才能进步。