如何从主机环境演变到云原生开发模式？

时代在发展，我们的知识，开发工具，以及相应的环境也随之进步，我们总是会趋向于向好的一面发展，期望我们自身能够更加优秀，更加高效，以及能够给周围的人带来更多的价值

那么在我们平日开发过程中，你们的开发模式，以及开发环境是如何演变的呢？ 如下是我近一两年经历的变化，希望能给你们带来一些思考和收获

混沌之初还是主机环境

起初在接触 golang 之前还是在使用 C 语言在嵌入式板卡上进行开发，那个时候 U盘，串口，各种外设，板卡，桌面上应有尽有，开发和调试相对也是比较麻烦的

尤其是在将编译完毕之后的软件烧录到嵌入式板卡中时，会等待一定的时间，短则 10 几秒，长则几分钟不等，就在等待的这段时间，就能看到一些同事刷手机，刷着刷着就忘记了接下来要做的事情

开始做 golang 之后，每一个仓库的打包都是依赖于同一份 shell 脚本，大致流程是

1. 拷贝相关配置到指定目录

2. 拉取同名仓库的依赖，例如 proto 文件，proto 文件我们是放在了另外一个专门存放 proto 的仓库中

3. 编译 proto

4. 编辑项目程序

5. 将可执行程序，以及相关配置文件做成 tar 包，并以时间命名再加上当时提交的的 commit 号前 8位

项目之初，各方面都还比较原始，优秀的框架也还没有人会

从 gitlab 上拿包转变成 cicd

前半年的开发模式都是自己在主机环境里面替换可执行程序

当然，这个可执行程序也是自己的开发机器上编译的，对于几个人同时开发同一个服务的时候，就会存在有人默默将自己本地可执行程序替换到开发环境上，导致影响他人，出现各种稀奇古怪的问题，排查一通，原来程序的版本都被换掉了

这段时间，如果是转测，我们是交付 tar 包

咱们开发就会从 gitlab 上拿 tar 包，给到测试人员，测试按照安装脚本来进行安装，然后查看日志无异常，则表示安装成功

慢慢的我们开始有了自己的流水线，但是交付的内容还是一个 tar 包，只不过，不需要开发将 tar 包发给测试了，而是测试自己去流水线上取包，安装即可

此处并没有给我们的整个流程带来多大的提效

开始使用 ansible 来进行提效

自然，我们上线的时候也能想象的到，对于每一个服务都是手动执行解压缩包，进入到安装目录，执行脚本安装服务

如果是一次升级涉及到多个服务，那么升级的成本那是相当大的，且如果升级出了问题，并没有立即回滚的机制，一般情况下会将问题排查出来，若无法得出结论，则会将上一次升级的包拿出来，再次升级一遍，结果就是升级失败了

那段时间，我们升级都是在晚上，顺利的话，也得凌晨升级完毕，若是出现异常的话&