数据库运维开发环境的调试模式演进

这是学习笔记的第2393篇文章。

昨日，同事反馈了一个问题，原本的办公机环境中的虚拟机可以将办公机的IP暴露出来，提供数据库运维的API服务。例如，办公机的IP为192.168.10.100，而使用VirtualBox的虚拟机采用主机模式，其IP可能为192.168.56.100，那么192.168.56.100上的API服务可以通过192.168.10.100进行访问。通常，开发环境测试完成后，代码会被推送到GitLab，经过验证后发布。因此，测试和线上环境都有各自的相关服务，IP方式模式相对固定。

听起来这似乎是一个简单的问题，但最近这种多服务间的联调模式出现了问题，如上图红色部分所示。如果使用桥接模式的IP，网络那边有明确的限制，也不可行，因此原本简单粗暴的测试联调需要转换思路。

我们考虑了一种新思路，即申请一台新的Linux服务器，保持与线上一致的环境，并开启桌面模式。这样，办公机可以通过VNC等方式连接到Linux服务器，然后在Linux下进行开发和测试，提交代码变更。这听起来是个不错的主意，而且统一的Linux环境还可以共享基础配置，避免了许多人重复配置环境的烦恼。整体设计如下图所示：

然而，这种模式存在一些问题。其中一个问题是测试Linux服务器上的代码时，每个人分别测试，但提交是个问题。如果要最大限度地保证效率，可能每个人都可以向主分支提交代码，这样会导致混乱，而且一旦发现冲突，就需要一个统一的角色来合并。此外，远程桌面的办公模式相对可行，但如果网络不够好，体验会很糟糕。退一步讲，本机开发的效率肯定是最方便最高效的。

期间我们也讨论了申请一台统一的Windows服务器，但由于Python依赖库的差异，我们无法确认在Windows上正常运行的服务是否在Linux上完全可用，因此这个方案很快被我们放弃了。

还有一种模式是我们在办公机上开发逻辑，假设通过某种机制将变更的代码先推送到开发服务器（Linux）上，那么这个服务就是一个相对固定的访问模式。如果开发联调中出现问题，可以不断调整，直到满足业务场景的测试。问题是，有什么机制可以保证我们可以随时将代码同步发布到IDC的开发服务器，如下图红色部分所示：

此时，我们想到了几种潜在的解决方案：

千帆大模型平台

面向企业开发者的一站式大模型开发及服务运行平台

0

查看详情

1）第一种，使用Filezilla在办公机上进行文件传输，也算是一种快速发布模式。

2）第二种，在办公机上配置一个bat脚本，实现从虚拟机上下载文件，然后推送到测试环境。

虽然这些方法都可行，但感觉流程还是缺少了一些东西，因此我们继续思考，提出了下面的方案，即在IDC测试服务器上配置一个WEB文件服务。默认的Python文件服务只需一条命令，但我们需要做一些额外的工作，即保证WEB文件服务可以上传文件，因此需要简单编写一个Python脚本来实现。改进后的方案如下：

这种方案的好处是我们可以制定策略，满足个性化的配置和快速发布。例如，有A、B、C三个人，他们可以在IDC测试服务器上使用不同的目录和不同的WEB文件服务，例如：

A，配置7001的API端口，配置9001的WEB文件服务。

B，配置7002的API端口，配置9002的WEB文件服务。

C，配置7003的API端口，配置9003的WEB文件服务。

如此一来，经过测试，整个过程可以随意发布和测试，且对其他人没有直接影响。测试后的代码可以根据测试情况提交，合并到主分支。

以上就是数据库运维开发环境的调试模式演进的详细内容，更多请关注php中文网其它相关文章！