使用VUE+TS+ANTD+PNPM实现天气查询应用
上一篇介绍了前端工程化的一些东西，说要从vue开始学习，那么相比理论，直接进行开发实例能够更好的理解工程化带来的便利。说说今天要做的小应用，上一篇介绍了轮播图，这次就是查询天气卡片显示。 先说说实现的核心思路： 1、监听城市名 2、接口请求 3、接口数据返回 4、动态渲染页面 看看实现的完成图： 那么这个天气数据哪里来呢？就是三方的天气API接口，比如国家气象数据中心，实名注册后每天有20次调用次数，足够使用了，也可以使用第三方平台给的接口，可以自己搜索。
前端工程化
今天和一个资深的前端开发前辈聊了聊，我说作为一个非专业的前端爱好者，该怎么快速学习前端的知识。这位前辈这样说，“你应该庆幸你是因为爱好才学习前端知识，而不是为了谋生而学习。还有从开始就不要把自己作为一个业余的开发者去学习，只要是你爱好的就应该成为学习动力，努力之后一定可以成为专业的开发者。”这番话对我感触挺大的，有爱好并为之努力，一定可以收获更多。 然后这个前辈就分享了以前学习前端的过程，就是先用记事本写HTML页面结构，然后加入CSS进行排版美化页面，后来再写一些js代码增加交互功能，根据实际需求，需要多少页面就创建多少个页面。 但现在的前端开发，早就进入了工程化开发的时代，已经存在有各种现代化的框架，编译工具以及预处理器等等。 下面就传统和工程化的前端开发优劣介绍下： 传统开发：没有采用工程化工具和流程的情况下进行开发，通常需要开发者手动管理文件、依赖和构建过程。 优势： 1、入门快，不需要额外学习配置工具和流程 2、灵活，根据需求喜好选择合适工具，直接操作DOM 3、轻量：没有复杂的构建和工具依赖，项目体积小 劣势： 1、效率低，手动管理较多，缺乏自动化工具和流程 2、维护难，没有统一的代码风格，团队协作难 3、难扩展，缺少模块化和组件化
下半年运维开发写作计划
转眼间上半年已过去，下半年已经开始了，努力搬砖中！这周打算主要介绍前端相关知识，奈何搬砖过程中遇到不少问题，暂时只能是想到哪写哪，先记录起来，后面抽空再统一整理。 截止今天，自己分享的已经从前后端开发到自动部署的基础知识都有所涉及了，上篇分享的gitlab-ci流程已经弄完了，不过都是用shell执行器实现的，文件内容就很简单，直接打包拷贝到nginx服务器而已。因为docker执行器一个是对于简单项目来说构建时间久，还有就是因为有网络环境隔离的原因，操作起来不是那么方便。 上半年运维开发写作计划中，从3月到6月主要就是从计算机基础、开发基础、前后端学习，以及开源项目的学习和开发这几个方面来写的。分享的基本都是基础知识，其实也是自己学习的过程，文章内容基本都是安装操作以及相关基础知识之类的。 https://mp.weixin.qq.com/s?__biz=Mzg2OTY1ODU4NA==&mid=2247485673&idx=1&sn=57dc973e6be7b79130cf4f48a1490c27&chksm=ce98f25ef9ef7b48bd8b2b367e16f38644e17da23fe93078c58a63db401f78bbb27117b4cdef&token=1357150504&lang=zh_CN#rd 那么下半年还是持续分享这几方面的知识，但是对自己的所写的文章要求肯定会高一点，一方面是督促自己，另一方面也是对自己读者的负责，毕竟已经有不少读者的关注，还是压力蛮大的。 “下半年就开始着重某一个点，比如从实战项目中涉及的知识点由浅到深解析学习，详细计划根据实际情况选择展开。”这是上半年说的，只是一个大概描述，我后来想了一下就拆分如下： 主要就四件事： 1、基础知识巩固 2、前后端语言以及云原生的持续学习 3、开源项目的维护
放空
放空的一天！
DOCKER执行器自动化部署VUE项目
今天接着上次，使用gitlab中的cicd功能自动部署vue项目，如果全部使用shell执行器，肯定是可以的，就是要提前在runner宿主机或者远程部署主机上安装好node环境以及其他依赖的环境，这里今天尝试的是docker执行器，构建操作在docker中完成。 首先是chatgpt给的CI的范例： 定义一个stages阶段，包括build、test和deploy stages: - build - test - deploy # 定义构建阶段 build: stage: build image: node:latest cache: paths: - node_modules/ before_script: - npm install script: - npm run build # 定义测试阶段 test: stage: test image: node:latest cache: paths: - node_modules/ before_script: - npm install script: - npm run test # 定义部署阶段 deploy: stage: deploy image: node:latest before_script: - yum install -y nginx script: - rm -rf /usr/share/nginx/html/* - cp -r dist/* /usr/share/nginx/html/ - systemctl restart nginx 但这里有几个问题：
流水线使用浅谈
使用总结 通过前面的分享，我已经在自己的环境中安装了gitlab-runner和jenkins，我以前用的是脚本全自动部署，所有操作都是由shell执行器完成，并没有涉及docker执行器。然后今天我就分享下，对于gitlab-runner执行器的一点认识。 jenkins和gitlab-ci 有读者有疑惑，为什么先用gitlab-ci而不是jenkins，我这里就来简单对比下，gitlab的流水线和jenkins的流水线。 安装和配置: GitLab CI:作为GitLab的一部分,安装简单,配置也较简单。 Jenkins:独立工具,安装和配置较复杂,需要配置各种插件和环境。 使用难度: GitLab CI:配置简单,YAML格式的配置文件,易上手,学习曲线平稳。 Jenkins:功能强大,但配置繁琐,需要编程来实现较复杂的任务,学习曲线较陡。 与源码管理的结合: GitLab CI:原生集成了Git,非常易于与GitLab仓库结合,可以自动检测仓库更改并运行流水线。 Jenkins:可以结合各种源码管理工具,但需要手动配置触发器来检测更改。 可扩展性: GitLab CI:可以安装GitLab Runner来扩展,支持与Kubernetes集成,较易于水平扩展。 Jenkins:本身支持分布式部署,有大量插件可以连接不同环境,扩展性高但复杂。 预置环境和资产: GitLab CI:没有预置的环境或资产,每次运行流水线时会创建独立环境。 Jenkins:有丰富的预置环境、凭证、缓存等资产,可以重复使用,但也增加了管理难度。 那么到底如何选择： GitLab CI简单易用,但功能略少,扩展和管理也相对简单。适用于中小型项目。 Jenkins功能强大,但较复杂,需要投入更多时间去管理与扩展。适用于大型项目。 两者可以很好地结合使用,例如使用GitLab CI进行 daily build,使用Jenkins进行发布管理。
使用JENKINS-2.401.1
gitlab-ci使用 接着上篇文章，先将项目上传至gitlab，其中包含编写ci文件，然后就会自动检测到并构建运行ci文件。 这个gitlab-ci文件要在项目中的根目录中，形式如： .gitlab-ci.yaml 在这个文件中，可以定义： 脚本 配置文件 命令 要部署到的环境位置 比如官方给的举例：
今日焦虑
嗨，写有质量的文章真难。还是慢慢磨吧！学习可以慢但不能停止。 写一两篇文章简单，持续输出就难。但也不能持续输出垃圾啊！
GITLAB-RUNNER跑起来！
CI/CD 总体概括 CI/CD 是持续集成(Continuous Integration)和持续部署(Continuous Delivery/Deployment)的缩写。 持续集成Continuous Integration 持续交付Continuous Delivery 持续部署Continuous Deployment
GITLAB-16.0.2！
安装gitlab-runner 中文版本官方文档： https://docs.gitlab.cn/runner/install/ 看官方文档，有以下理解： gitlab-runner开源，使用go编写，可以作为单个二进制文件运行，没有特定语言要求。 可以使用docker部署或者部署到k8s集群。 可以在linux、macos、freebsd、windows平台安装使用。 部署方式： 容器中 手动下载二进制文件 使用rpm包安装 注意：出于安全和性能原因，不应该在托管GitLab 实例的机器上安装GitLab Runner。 今天我们选择使用yum方式安装，因为是centos系统使用居多，用yum管理也比较方便。