从零打造自己的CI/CD系统|CD的演进之路
每个公司的
CI/CD系统都是从最开始的刀耕火种时代到所谓的自动化时代慢慢演进的一个过程，期间可能会有各种各样的问题存在，有的公司借助开源工具来实现，也有公司在开源的基础上进行二次开发来满足公司的需求，团队规模很大的情况下一般会选择自研来满足高频迭代的场景需求。以下我们简单罗列下演进的几个阶段，后续我们会按照这个顺序进行文档的编写。
鸿蒙之初
•针对不同的项目编写与之适配的shell脚本•OPS跟着项目跑，因为要做不同的场景的适配•把脚本的公共部分抽出来复用•能解放一部分时间，但是约束依旧是很小
旭日东升
开始关注软件工程和基础设置组件，并在基础设置组件的基础上进行组合
•Jenkins•job display•Python|Golang•Config Center api enable or disable•Ansible•pipeline•rolling update•jenkins job auto add and remove•Nexus•npm•maven•composer•pypi•docker•Gitlab•代码仓库命名规范•包的放置位置规范•Config Center•Config pull or push•SmokeTest•check service work fine or not•Monitor•enable monitor or disable when deploy•Log•log keyword monitor
阳光正好
前置条件(这块的知识可以看下前面的自动化运维基础建设文档)
•确定分支模型•统一工件库•配置中心、注册中心•代码质量平台•code review•代码规范检查•单元测试•用例测试•部署
Demo(后续文档的以以下罗列为基准编写)
•项目创建•功能编写•代码提交 [CI工具介入]•代码常规检查•自动化单元测试•依赖漏洞检查•功能自测•Code Review [CI工具介入]•合并发布分支 [CI工具介入]•自动构建 关联工件库 [CI工具介入]•mvn | composer | npm | pip•vm•docker•多阶段构建•deploy release to nexus•自动部署 [CD工具介入] 滚动部署•将构建的包sync到rs机器上，以当前时间戳创建临时目录，原则上远程机器上保留历史的N次部署版本的war包,方便秒级回滚•这个构建后的包的获取方式有两种•一种是直接从nexus拉取releases包•如何从nexus上获取最新的releases的包•一种是每次部署的时候重新进行编译动作•同步的机器的信息从哪里获取?•CMDB的价值•disable slb•nginx•nginx health check•slb•api•disable monitor•stop service•check service status•check smoketest•check port•replace package•start service•check service status•check smoketest•check port•enable monitor•enable slb•next machine step by step•产品发布 [CI/CD工具介入]•APM监控•大网监控•人工观察线上质量 [CI工具介入]•日志告警•监控告警•质量修复、持续改进（循环第3步开始的内容）
总结
以上所列的Demo, 真正的落地是需要很多先决条件的，并不是单纯的把一个工具写出来就够了，约定大于配置，如果团队达不成共识，依旧各自为战，到头来依旧是OPS被项目赶着往前走，各种救火，我个人认为一套比较简单易用CI/CD系统这块是能够很大程度上解放OPS劳动力的一个大方向，以上所列仅代表个人观点，可能不够完善，适合自己的才是最好的。
