2022年底,我手里一共负责了30套系统

时间:2022-12-18 13:03:12

2022年真是不平凡的一年,往常熙熙攘攘的办公室人越来越少,真是像曹操说的兄弟相继凋零,好似风中落叶啊。

结果人少了,手里的系统一个没少,慢慢年底了,我汇总了一下,手里的系统达到了30来个。

搞不定怎么办?我是这么做的

 2022年底,我手里一共负责了30套系统

目录

1、 区分系统的重要程度

2、P3级别的文档梳理

3、P2级别的文档梳理

4、P1级的文档梳理

5、把前端代码部署到nginx服务器

6、还要学用sequlize操作mysql数据库


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平台 --

名人名言:当你离目的地更近一站的时候,你会发现,可能到目的地的公交车就会多一趟。