vibe coding全栈开发工作流（含运维）2
内容提要
文章介绍 vibe coding 全栈开发后的部署与运维实践：放弃无容器方案，改用容器与 Kubernetes；通过 GitHub Actions 完成测试、构建并推送镜像，再由 ArgoCD 与 image updater 自动同步更新；配置 readiness 与 liveness 探针，确保滚动更新不中断，并加入邮件通知；生产环境仅在手动将 dev 合并到 main 后更新。
延伸解读
为什么放弃无容器部署
作者明确对比了无容器与容器两种部署方式。无容器虽简单直接，但环境与本地开发存在差异，容易出现“我的环境没问题”的典型问题，且版本回滚不便、滚动更新需要额外操作。这解释了为何最终转向容器方案：核心诉求不是追求轻量，而是环境一致性、可回滚和滚动更新能力。读者可据此判断自己的项目是否值得承担容器化的复杂度。
ArgoCD 与 image updater 的分工
文章指出，若 K8s 部署 YAML 跟随代码仓库，代码更新会带动应用更新，但构建镜像与代码推送之间存在几分钟到几十分钟的时间差。解决办法是将部署 YAML 与应用代码分离，并部署 ArgoCD image updater 持续比对应用当前镜像与镜像仓库最新版本，不一致即触发滚动更新。这揭示了 CI 与 CD 之间需要额外机制来抹平构建延迟，而非简单依赖代码推送。
探针是滚动更新不中断的前提
作者特别强调，为保证滚动更新时应用不中断服务，必须妥善配置 readiness 与 liveness 探针。其机制是只有新服务完全可用后才会下掉旧服务。这意味着自动更新链路能否真正安全，不只取决于 ArgoCD 或 image updater，还取决于应用自身的健康检查配置。若探针缺失或配置不当，滚动更新仍可能造成服务中断，这是实践中最容易被忽略的一环。
生产环境只手动合并触发
文章提出，直接更新生产环境风险较高，因此只让预生产环境持续集成持续发布：每次推送代码只推 dev 分支，待预生产验证无误后，再在代码仓库手动将 dev 合并到 main，生产环境才会更新。这一设计把自动化的便利限制在预生产，把生产变更保留为人工决策点。同时作者建议配置邮件通知，在应用更新后发送邮件，避免需要一直盯着更新状态。
Q&A
为什么在 vibe coding 全栈开发中放弃无容器部署方式？
无容器部署虽然简单直接，但环境与本地开发环境有差异，难以保持一致，容易出现“我的环境没有问题”的问题；版本不好回滚，部署时也不方便滚动更新，需要很多额外操作，因此放弃。
容器化部署时，docker compose 和 k8s 分别适合什么场景？
如果只有一个应用且迭代频率不高，可以试试 docker compose；如果应用较多、迭代比较频繁，最佳方式是 k8s。k8s 虽然较重，但能掌控、社区强大、配套方案多。
GitHub Actions 在部署流程中具体执行哪些步骤？
GitHub Actions 的执行逻辑依次是：测试、构建镜像、推送镜像。
ArgoCD 和 image updater 如何配合实现应用自动更新？
ArgoCD 能将 helm chart 或 kustomization 应用作为整体持续同步更新；但构建镜像与代码推送存在时间差，因此将部署 k8s 应用的 yaml 文件与应用代码分离，再部署 ArgoCD image updater 服务，持续检查当前应用镜像是否与镜像仓库最新版本一致，不一致就滚动更新。
如何保证滚动更新时应用不中断服务？
需要妥善配置 readiness 和 liveness 探针，这样滚动更新时只有新服务完全可用才会将旧服务下掉，从而不会中断服务。
生产环境如何避免被直接更新导致崩溃？
只让预生产环境持续集成持续发布，即每次推送代码只推送 dev 分支；等预生产环境没有问题后，才在代码仓库手动合并 dev 分支到 main 分支，这样生产环境就会稳定一些。
应用更新后如何及时获得通知？
可以配置通知机制，通过邮件的方式在更新应用之后发送通知邮件。
