vibe coding全栈开发工作流（含运维）2

上一篇文章交代了开发的流程，到了GitHub Actions就断了，这篇文章从这里继续。

对于一个产品而言，开发出来只是很小的一步，编写完成一个功能也是，后需要还需要测试，需要部署，需要持续的迭代和维护。

部署一个应用大致有两种方式，使用容器和不使用容器。

首先来谈谈不使用容器，不使用容器其实比较好部署，直接同步代码，然后服务器启动，好处是简单直接，但是环境因为跟本地开发环境有差异，其实很难保持一致，所以会出现“我的环境没有问题”的问题，以及版本不好回滚，部署的时候也不方便滚动更新，需要很多额外的操作，所以我放弃了这种方式。

使用容器的话，其实没有太多部署方案的选择，如果你只是一个应用，迭代的频率不高可以试试docker compose，如果比较多的应用，迭代比较频繁，那么最佳的方式就是k8s，虽然对于很多人来说，这个方案比较重，但是，个人还是比较喜欢的，因为能够掌控，社区强大，有很多配套方案。

选择了，部署方案就可以选择Actions的执行逻辑了，首先是测试，然后是构建镜像，最后推送镜像。

镜像推送之后就不管了？

是的，为了，让应用能够自动更新，我们需要一些CD的服务，我选择的是ArgoCD, 它能将一个helm的chart或者kustinization 应用作为一个整体，持续的同步和更新，如果你的应用的那些yaml文件是跟着代码仓库走的，那么代码更新就能带动应用更新。

不过这样，你需要一些额外的机制来抹平构建镜像和代码被推送到代码仓库的时间差，因为构建镜像肯定在代码更新之后，可能几分钟，也可能几十分钟。

所以，你可以将部署k8s应用的yaml文件跟应用代码分离，然后再部署一个ArgoCD image updater的服务，这个服务会持续的检查当前应用的镜像是否跟镜像仓库的最新镜像版本是否一致，不一致就滚动更新。

值得注意的是，为了保证滚动更新时应用不中断服务，你需要妥善的为自己的应用配置readiness，liveness探针，这样滚动更新的时候就不会中断服务，因为只有新的服务完全可用才会将旧服务下掉。

至此，代码开发的CI/CD基本完成了，推送代码之后应用就自动更新，不过还有一些小细节可以补充。

第一就是，我咋知道是时候更新了应用？总不能一直看着吧，所以你可以配置一个通知机制，通过邮件的方式在更新应用之后发送通知邮件。

第二就是，直接更新生产环境很危险呀，万一手抖或者其他原因把生产环境搞崩了，咋办？所以，直接更新生产环境不太稳当，除非你对自己绝对有信心，而生产环境偶尔挂一下也没啥影响。

因此，我们应该只让预生产环境，持续集成持续发布，即每次推送代码只推送dev分支，等预生产环境没有问题之后才在代码仓库手动合并dev分支到main分支，这样生产环境就会稳定一些。

预览时标签不可点