大家好~我是
米洛
!
我正在从0到1打造一个开源的接口测试平台, 也在编写一套与之对应的教程
,希望大家多多支持。
欢迎关注我的公众号米洛的测开日记
,获取最新文章教程!
# 回顾
上一节我们编写了日志模块
相关的改造,这一节我们继续趁热打铁,来继续丰富我们的系统。
# 配置的问题
我们目前系统的配置算是一个很简陋
的版本,由于我习惯了在生产环境
(这里指的是pity的生产环境)进行开发,所以很多时候我的配置直接就写死为pity的生产配置。
但这显然很不合理
,因为以规范的开发模式来说,我们如果是测试环境或者开发环境,我们一般会连接dev的数据库/redis等中间件。
这样我们才能做到,在进行新功能
开发的同时,不影响到线上的数据。
# 举个例子
我现在用户表要修改一个字段的类型,从varchar改为integer。此时注意我们线上的代码依旧是以varchar的形式运行的。
如果我们本地测试的时候改掉了字段,那线上的代码运行到那块的时候就会出现类型不匹配
的问题了。目前pity还没啥人在使用,如果大家已经开始在自己公司使用了,那新功能开发的同时就会影响到已有的代码。
# 解决方案
其实这块解决方案,我见过的公司都是采用环境变量
的方式来解决的。比如服务启动的时候,会自动去系统变量
获取某一个特定的变量值,举个例子叫: pity_env
。
如果这个值为DEV
,则使用DEV
的配置数据,如果是其他环境,则用其他环境
的配置。所以解决起来相对还是比较简单的。
不过要注意到,我们的configuration.json也要区分环境哦,没关系,我们一起改造就可以了!
# 行动起来
首先第一步我们要确认一下我们到底有多少环境,复杂点的话,可能需要DEV/UAT/PRO等多种环境,毕竟我们的代码也需要测试,跟着开发的节奏走。不过这里我就不搞那么多环境
了,我们只分DEV和PRO环境即可。
修改config.py
我们只需要写个
基础配置类
,接着不同的Config继承之即可。所以我们拆出公共变量:
接着分开给出DevConfig和ProConfig,最后做一个判断:
# 获取pity环境变量
PITY_ENV = os.environ.get("pity_env")
# 如果pity_env存在且为prod
Config = ProConfig() if PITY_ENV and PITY_ENV.lower() == "pro" else DevConfig()
2
3
4
先获取pity_env的值,如果有且为pro,则是生产环境,否则则是pro环境。
这样也有一定的风险,即开发其实可以本地改成pro环境,但在企业里面pro环境和其他环境一般是隔离了的,所以就算你配置成Pro的环境,也访问不到pro的数据库等(相对来说会严谨很多,所以这么做也没啥毛病,大胆放心去用吧!)
为了不影响之前的代码,我们特意创建了
一个Config变量,和之前保持一致。
# 改造configuration相关内容
- 我们把现有的configuration.json改为configuration_dev.json并复制一份,命名为configuration_pro.json。
- 编写获取文件名的方法
- 调整获取和update相关方法
# 测试一下
为了更帅气一点,我们可以加上之前学过的banner和当前环境标识,以日志的形式打印出来。先看看最终效果:
- 添加环境变量
在初始化日志之后打印相关banner提示
在main.py初始化logger后加入以下语句:
from config import BANNER
logger.bind(name=None).opt(ansi=True).info(f"pity is running at <red>{PITY_ENV}</red>")
logger.bind(name=None).info(BANNER)
2
3
4
- 在config.py底部写入banner
BANNER = """
________ ___ _________ ___ ___
|\ __ \ |\ \ |\___ ___\ |\ \ / /|
\ \ \|\ \ \ \ \ \|___ \ \_| \ \ \/ / /
\ \ ____\ \ \ \ \ \ \ \ \ / /
\ \ \___| \ \ \ \ \ \ \/ / /
\ \__\ \ \__\ \ \__\ __/ / /
\|__| \|__| \|__| |\___/ /
\|___|/
"""
2
3
4
5
6
7
8
9
10
11
# 从效果图可以看出,我们打印出了当前的环境, 超赛神pro。
今天的内容就分享到这里,大家也可以试试给自己的项目加点帅气的banner
.