CI/CD

gemini3 发布几天了。都说很叼，前端很叼，画页面很牛。那就帮我画个工具箱吧 设计 于是打开 chatgpt 和他讨论一下，主要思想就是我希望前端能够非常的模块化 写一个工具的时候，不需要关注太多和我网页的配合。按照一定的规范写完工具后放在指定位置就行了。基于 git 我就可以审核后发布，前端就可以在某个目录某个地方看到这个工具，搜到这个工具。暂时不考虑性能问题 gemini3 目前我两个用的地方，一个在 ai studio 里面直接用，另一个就是在 cursor 里面用了，姑且信一把 cursor 开搓 接一杯水的功夫出来了。这个设计很符合我的概念（但是我本能的觉得性能影响很大，以后堆积越来越多的工具，一打开我的网站，啪的一下要下载好几十MB 的内容。） 编译预览一下，这期间有一点小问题，反正我也不是很懂前端，他给修好了 随后上点强度，一口气提了 9 个比较常见的网页工具，一次性完成。 可以，很满意哦，回头做个深色浅色模式随系统切换 部署 那么想把它部署起来，在这整个工具箱的设计里，是存在后端的，因为对于我的需求而言 有一些工具我是希望他有历史记录的，当然量不是很大。所以一开始我是想部署在自己的 VPS 上。但是想了一圈后犯懒了（原本想基于 github 的 webhook 或者 actions build & push docker images，服务器搞个小 deploy agent 等着更新就行）有 github pages，不如直接放在 pages 里就好了 叫 g 老师给写个 actions 关于 actions 的文档和介绍 GitHub Actions 入门教程 - 阮一峰的网络日志 GitHub Actions 文档 - GitHub 文档 因为我的仓库内有前后端的代码。所以 working-directory 指定 frontend ...

写在前面 在公司偶尔会同时维护三四个甚至五六个项目。稀烂的项目管理导致每次快速更新迭代时部署成了重复性超高且烦人的事情 部署流程 由于原先开发规范不够，git 使用不足，所以暂时一直拖着。现在对项目管理严抓想起来这件事情。 Javaer 一定见过下面这个 Jenkins 。这是个Java 编写的开源的持续集成工具 持续集成是啥意思，CI/CD 啥意思 解释：CI/CD或CICD通常指的是持续集成（英语：continuous integration）和持续交付（英语：continuous delivery）或持续部署（英语：continuous deployment）的组合实践 from wiki 这就能懂啦，我对前端不是很明白但是现在我们的开发流程一般是 1 前端同学开发完毕->build->发 dist 给管服务器的同学->（往往是我），我把 dist 放在对应的 nginx 目录下 如果他不发给我的情况。我就需要 1 git 拉取源码-> npm 更新依赖 -> build -> mv to nginx/html 那么这里很明显是可以通过 github/gitlab 的通知机制实现自动化部署的 Webhooks 凑巧找到一篇文章完美作为教程 【CI/CD】写给前端的自动化部署攻略序 ​ 对于前端开发而言，静态页面的部署是容易的。只需要将打包好的页面，放入已经配 - 掘金 简而言之，git 仓库会提供 webhooks 功能。就是如果你对仓库做了某些操作，git 将通过 http 向你提供的地址发送操作信息（json） 这里这位佬用的 gitlab 做的例子。我们自部署的也是 gitlab，太好了 这是新建 webhooks 的页面 我们暂时不用 release ，所以就以 tag push event 作为发布的信号 ...