看版也有软件开发环境？

15

2023-08

看版也有软件开发环境？

周日分享了一个power bi环境部署的踩坑经验，读者群里扯起来了这么一个话题，于是我们来聊聊dev\uat\prod\test\sit等环境到底是什么玩意~

LEARN MORE

图片由海艺AI绘制

先说软件开发环境

既然提到了看板的环境，那就得先说说软件开发环境的相关概念：

pro环境：

生产环境，面向外部用户名思义，是指程序开发时所用的环境。程序员在编写代码时所使用的环境，一般来讲，开发环境中的服务器配置比较随意主要是用来测试的，无用户交互，并且要打开错误报告，方便程序员调试。的环境，连接上互联网即可访问的正式环境。

uat环境：

验收测试环境，主要面向要交付的人员进行验证测试。要理解UAT环境，首先要明白UAT的概念，UAT，(User Acceptance Test)，用户接受度测试 即验收测试，所以UAT环境主要是用来作为客户体验的环境。一般来说，就是给需求方测试用的环境。

pre环境：

灰度环境，外部用户可以访问，但是服务器配置相对低，其它和生产一样。这种一般是to B 卖软件的公司会有，就是一套和真正使用的环境一样的环境（即已经出售给客户的系统所在环境，也成为商用环境），所有的配置，页面展示等都应该和商家正在使用的一样。

test环境：

测试环境，外部用户无法访问，专门给测试人员使用的，版本相对稳定。公司内部研发人员使用的环境，开发人员调试代码，测试人员进行功能测试和集成测试等等使用的环境。和UAT环境都是用来测试的，但是测试的人不一样，UAT环境测试的人是用户，是需求方，是非开发人员；但是test环境是专业的测试人员测试用的。

sit环境

系统集成测试，开发人员自己测试流程是否走通的环境。和test环境相比，sit是写代码的程序员测试用，test是做测试的程序员测试用。

dev环境：

开发环境，外部用户无法访问，开发人员使用，版本变动很大。顾名思义，是指程序开发时所用的环境。程序员在编写代码时所使用的环境，一般来讲，开发环境中的服务器配置比较随意主要是用来测试的，无用户交互，并且要打开错误报告，方便程序员调试。

虽然环境辣么多，但不是每家公司都有所有的环境，一些环境要不要配置和公司的业务有关系，比如pre环境，to B卖软件的公司一定有，但是非这个业务的公司就没有。但不管怎么说，公司至少都会有三套环境，即开发、测试和生产。

怎么用软件开发的思路做看板

很多时候，我们在做数据看板的开发的时候是不会参照软件开发的思路进行开发的。

一个显而易见的道理，数据看板是要服务于客观真实的数据的。一个在测试环境正确的SQL逻辑，到了生产环境中未必是正确的——测试环境可能有脏数据或者有一些生产环境中存在的问题测试环境是不存在的。

然而有一种例外情况，那就是当数据看板需要承接的数据量非常大的情况下，开发看板的时候就需要慎重一下考虑环境了。管道部署这种功能，目前就我所知道的BI工具来说，power bi应该算是独一份的，就像上面说的理由那样，其他的BI工具其实没有特别严格的dev、uat、prd环境的区分。但是power bi在大型模型开发的过程中是会拆分环境的。

根据微软官方的最佳实践来说，一个大型的项目开发是这样的：

在项目开始的时候，我们需要建立6个工作区，分别是dataset的dev/test/prd工作区和report的dev/test/prd工作区。然后配置好pipline，在pipline中指定三个工作区的名字即可，操作起来也是非常简单，直接点一下就好了。

然后开发人员就可以进行dataset的开发了。一般情况下，我们做小看板的开发，都是直接连接数据库的，把数据导入本地进行开发的。但是对于上亿条数据的大模型而言，这样开发显然不行，且不说导数据需要很长的时间，开发人员的办公电脑铁定支持不住。对于大型模型的开发，通常会把数据库的访问地址写在一个参数里面，然后在power query中访问数据库并调取数据的M语言中的数据库地址写成配置的参数。

（顺便提一嘴，这里参数写了一个localhost是因为可以通过powershell实现了SSH隧道的连接）

基于这种方式进行dataset的开发是有一定难度的，也就是说日常点点点这种办法不是特别可行，需要直接手撸代码。当然，一般情况下，开发人员会选择用dax studio，TabularEditor，sql server management等等外挂出来协助。

确认dataset没啥问题之后，会发布dev工作区，实际连接到数据库的数据，刷新一下数据测试一遍看看有没有什么问题，然后反复调整（此处就省略过程了）。

然后新建一个power bi文件，获取数据源的时候直接连接刚刚发布并刷新了数据的数据集，进行页面的开发。这样操作，就完美避开了把数据拉到本地等加载的问题。然而这就对开发能力有一定的要求的，实际操作中说是这么说，但是盲写M code和dax对多数人来说还是很有挑战的，一般不这么干。

开发完毕且内测完成之后，就会进入到UAT的环节了。从操作上来说其实不难，就是在管道中把datase和report分别发布到UAT环节，修改参数为UAT环境的数据，设置访问权限，创建应用并分发给用户。

为什么看板开发要拆分环境

对于这种大型模型的开发，一定是要基于数仓的。直接基于业务系统做看板的话是不会搞拆分环境这么复杂的操作的。

既然已经说了是大模型，拆分的原因之一，就在于数据量太大了。一般来说，dev环境的数据是非常少的，刷新一次非常快，不然改一个逻辑，刷新用了半小时，一看，改得不对，不是很崩溃么？

UAT环境的数据一般是从生产环境直接同步过来的，主要做两个事情：①用来给用户测试&提迭代需求用——用户在真的看到看板和数据之前经常提不出需求，但是看到之后就会提出一大堆的需求；②用来测试看板的逻辑是否能跑通，看板的开发和it开发有一个比较大的区别，一般来说it开发测试环境能跑通生产一定能，但是看板不一样，别说测试环境和生产环境了，昨天还正常的数据，今天就有可能崩——一条脏数据直接搞崩一个模型。

PRD环境的就是真正分发给报表用户看的，要保持相对的稳定，出现问题需要及时干预和解决。

一个有意思的事情是，看板的DEV/UAT/PRD和数仓不一定同步。对于DEV环境里的看板，有时候会选择连接数仓UAT环境里的数据，用于验证开发逻辑是否正确，UAT环境里的看板又会连接数仓PRD环境里的数据，用来校验数据的准确性，特别是有XX数据和XX数据逻辑上应该完全一致这种场景存在的时候。除此之外，一般情况下，生产环境会配置比较好的服务器和资源，UAT环境则不会，并且一般也不会给UAT环境的报告配置自动刷新什么的。

做拆分和创建应用并分发还有一个好处，那就是用户手里的URL连接不会因为修改或者其他改动而发生变化，这对于大型企业来说非常重要——不然经常有人问为什么报告打不开了。

然而一个例外的情况就是我周日提到的部署失败的问题，一旦遇到部署失败，被迫删除了UAT环境的数据，按照新增的方式重新进行部署，相应的URL连接就会发生变化，非常让人恼火。不过好消息是用户不会有dataset和report的访问地址，只有分发的应用的地址，而应用的地址并不会发生改变，算是不幸中的万幸吧。此外，因为URL连接发生了变化，移动端嵌入企业微信的配置信息也需要做相应的变化，总之就是一旦发生失败的问题，就有一大堆东西需要修改。