2022年真是不平凡的一年,往常熙熙攘攘的办公室人越来越少,真是像曹操说的兄弟相继凋零,好似风中落叶啊。
结果人少了,手里的系统一个没少,慢慢年底了,我汇总了一下,手里的系统达到了30来个。
搞不定怎么办?我是这么做的
目录
1、 区分系统的重要程度
当然这30来套系统也不是一次性过来的,是经过一年断断续续到我手里的,刚开始每人手里都有自己负责的系统,慢慢3月份一点,6月份一点,8月份一点,10月份一点,2022年真是不平凡的一年啊。
根据重要紧急程度,我区分了P1 P2 和 P3三个等级。
P3就是线上还在跑着的系统,但是访问量比较小,而且几乎一年了也没有什么需求的;
P2就是线上跑着,也有访问量,需求偶尔会提1个,但不会去做太多投入,除非有重大改动的,不过看今年这情况,短时间内也不会有大的改动了,但是不是促销活动还是会动一动,属于三四个月可能会动一次的;
P1就是比较重要的系统,访问量比较大,几乎每次迭代都会提需求的。
2、P3级别的文档梳理
P3级别相对来说不太重要,因为只要线上机器不会坏就没事。但是一旦自己负责了就得有个样子,针对这P3级别的8个系统,我做了一个统一的文档。
记录了以下几点:
△ 代码的地址(保证自己有master权限)
△ 保证代码可以本地启动起来,修改代码可以生效
△ 知道这8个系统都部署在哪台机器上
△ 线*问的地址是什么
这样就够了,这种系统一般不会动,除非机器坏了,一旦哪天机器坏了,我再重新保证能部署到合适的位置就好啦。
3、P2级别的文档梳理
P2级别的日常不用动,但到了某个特殊的节日,还是会做一些活动处理的,所以我做了以下梳理:
△ 每个系统记录一个文档
△ 记录代码库的地址(保证自己有master权限)
△ 记录每套系统的npm源,node版本,保证与之前开发者统一
△ 代码可以启动起来,修改代码会生效
△ 大体梳理代码结构并形成文档,例如有前端路由的,要找准路由对应的组件,如果用了vuex redux的,证明这是一套比较麻烦的系统,还要多梳理一下数据走向(很多人为了锻炼用vuex,一个小破页面也用上,好烦)
△ 通过以上梳理,看一下打包的时候是否区分版本号,是否区分部署环境等,找准测试环境和线上环境的机器,都记录下来
△ 线上部署的时候,HTML和静态资源(js css image)是否在一起,是可以几台机器一下都重启,还是分批重启,冷备一部分
△ 记录线上地址,查看线上和测试的接口区分
△ 一般服务端同学不用记了,因为也只有那么俩人了
△ 代码细节也不用着重梳理,有时间再梳理也行
这样,保证自己需要做需求的时候,可以快一些找到修改的位置,改完了可以做代码部署,自测以及通知测试怎么测
4、P1级的文档梳理
P1级别的,可能每天都需要关注,文档中除了以上的P3P2级别的梳理文档,还有如下几点重要事项:
△ 梳理代码细节,子组件的嵌套关系,组件间的数据传递情况,展示情况
△ 着重梳理数据来源,接口是哪些,入参是哪些,出参是哪些
△ 梳理关键数据的兜底情况,是否会因为某些数据下发的不同而产生不同的情况,或者直接造成八阿哥
△ 交接给你的人,一定追着问,之前还有哪些坑,哪些没解决的问题,这一点至关重要;
△ 梳理这套系统中哪些功能更常用,需要立刻梳理代码细节,有哪些不常用甚至废弃的,还没有删除的
△ 了解这些系统的监控系统都有哪些,是否需要添加自己为处理人的,或者更加重要的系统,自己每过半个小时就需要自己去手动访问一次的
等等等等吧,问题很多,弄不过来,再区分也弄不过来。有人说技多不压身,但是活儿多了压身啊。
5、把前端代码部署到nginx服务器
有些系统代码因为历史原因,不能通过部署平台的,需要自己往线上nginx平台部署。之前要么都是前端把dist压缩包发给服务端,让服务端部署,要么就是有了部署平台自己玩,这下好了,我得自己往nginx线上服务器上部署。步骤如下(学的比较浅,但是暂时够用)
1、npm run build 打包
2、打出的zip压缩包之后,传到服务器上的某个位置
执行 scp -r dist-2022121201.zip dbg@xxx.xx.xxx.x:/home/dbg
这里的dist-2022121201.zip就是你本地dist打出的压缩包
dbg是你在线上机器的用户名
xxx.xx.xxx.x 是线上机器的ip
/home/dbg 是你在线上机器的某个文件夹,属于你自己的文件夹
3、登录到线上机器
执行 ssh xxx.xx.xxx.x
4、登录上去以后,就到了你自己的空间,然后执行 ls ,如果刚才传送成功了,是可以看见你刚刚打出的 dist-2022121201.zip
5、从你的空间,把压缩包移动到部署位置
执行 mv dist-202212121201.zip /usr/share/nginx/dbg_area
/usr/share/nginx/dbg_area 这是你nginx机器上的部署代码的区域,这里面将会放你的前端代码
6、将执行命令指向到nginx服务器位置
执行 cd /usr/share/nginx/dbg_area
7、再次执行 ls 命令,查看是否已经把压缩包移动过来了
8、解压压缩包,就会把上一次的内容覆盖掉
执行 tar -zxvf dist-202212121201.zip
9、重启nginx
nginx -s reload
其实先把压缩包移动过来再解压显得有点冗余,完全可以直接执行 tar -zxvf dist-202212121201.zip -C/usr/share/nginx/dbg_area,不过前端需要的nginx的知识点不过,就是部署一下,哦,对,有的项目用的nginx路由指向前端机器,这个也需要关注一下
6、还要学用sequlize操作mysql数据库
这里先大体写个步骤吧,每天事太多了,还没来得及梳理呢,改天梳理上。
印象最深的是后端java大哥告诉我,不能把mysql数据库密码写到代码里,要以文件形势加密写入到机器的某个位置。
而系统里需要先读取文件,再解密,再去做为连接池,去操作mysql数据库。
哦,对了,本地还装了个破mysql ,还弄了个免安装的小海豚,可以自己建表玩。
快要2023年了,感觉今年的冬天,好冷啊
-- 经海路大白狗 记录于 2022年12月 某个寒冷的星期六、五棵松 - CSDN平台 --
名人名言:当你离目的地更近一站的时候,你会发现,可能到目的地的公交车就会多一趟。