长文预警:关于明道云应用多人协作和应用分发的一点想法

产品 多人协作开发二次开发应用分发  收藏
8 / 2063

明道云团队你们好!一直以来都有关注明道云的产品,在明道云的 Web 端开源发布会后,我也马上部署了一个社区版并着手将公司其中一个产品「明道云化」,也打算通过明道云伙伴体系来拓展业务。经过一段时间的使用,和以前用其它 APaaS 平台的经验(市面上的近 10 款主流 APaaS 平台我已经基本上用了个遍)对比下来,说吊打其它平台吧稍微有点夸张,但明道云的应用搭建在同类产品中的确做到了功能性和易用性的平衡,强大且优雅,属于不用看帮助手册就可以上手的平台。感谢 Phil,感谢薜老板和明道团队。

当把自己代入合作伙伴的身份之后,作为一个「应用生产」者,在使用过程中也发现的确也有些许不便——特别是在团队多人协作以及应用分发方面。因为我曾经有过设计开发 Web IDE 的经验,所以用得不爽的时候就难免有些手痒。经过一段时间的思考,我想提一些不太成熟[谦虚脸]的想法,希望供明道团队参考。你们的产品力非常强大,我在应用搭建协作和分发方面班门弄斧一下,有可能我列出的问题你们已经解决了处于未发布的阶段而且极有可能比我的主意更加棒,希望你们不要介意。另外因为我们公司目前在探索零代码方向的只有我带着两个同事参与,所以没有购买 SaaS 版,以下内容都基于 v2.9.0-beta.1 社区版。

目前使用明道云平台我遇到的问题(题干)

  1. 多人协作搭建应用的过程中,每个人都可以随意改动所有的工作表和工作流,而且大家还可能同时打开同一个工作表编辑,会出现一定机率的误删除和误修改,导致工作流失效或工作表关联出问题。
  2. 工作表没有「版本」或「历史」的概念,内容被误删除后用户几乎无法自己恢复。
  3. 缺少集成测试环境,应用一旦正式使用,只能在「生产环境」上进行「功能扩展」,在此期间,如果涉及到修改和调试原有的工作表工作流,则意味着应用可能会在「生产环境」上出现「某些问题」。
  4. 作为应用服务商,只能做整个应用整体的导入导出或者整体发布到应用库,无法实现「制作升级包」或「增值模块」这样的功能
  5. 作为应用服务商,一旦用户在安装应用后自己又做了某些工作表工作流的修改或增加了新的工作表工作流,则此应用后续的升级只能依靠纯人工复刻实现了。

解决方案

我觉得存在以上问题的核心,在于「明道云」的应用搭建目前还缺少了传统代码开发中很重要的一环:「版本控制」。所以,要围绕「版本控制」功能的设计来解决以上问题。

传统代码开发中,我们一般会用到 SVN 或者 Git 来做版本控制,所以,完全可以仿照 SVN 和 Git 的思路来实现零代码应用的版本控制,只是,要做得符合明道云的优雅调性,需要在产品设计上下不少功夫。如果是我来做,大概会增加下面这些功能:

  1. 为工作表和工作流增加「锁定」功能;
  2. 为工作表和工作流增加「版本」功能,并增加部分工作表与工作流的导出导入功能;
  3. 为应用增加「分支」功能,并增加「分支应用」的更新、合并功能和导出发布「功能升级包」的功能;

前两点是为自己搭建应用的用户增强多人协作的体验,实现到这两点基本上已经可以解决上面的大部分问题,第 3 点则是为应用服务商增强应用分发体验,方便同时维护多个不同版本的应用。

以下是具体的实现方案:

一、仿照 SVN 的「取出」和「存回」概念,在工作表和工作流上设计「锁定」和「解锁」的功能。以解决多人协作搭建应用过程中涉及公共的工作表或工作时,能互不修改对方的逻辑。

功能要点:

  1. 当工作表被某个成员「锁定」后,则该工作表的「编辑字段」只能被该成员编辑,表单对其它成员「只读」。但「表单设置」和「公开发布」其它成员仍然可以操作;
  2. 当工作流被某个成员「锁定」后,则该工作流只能被该成员修改,对其他成员只读;
  3. 被「锁定」的工作表和工作流,只有当锁定者对其「解锁」后,其它成员才能再次「锁定」;
  4. 为保持向前兼容,在未「锁定」情况下逻辑不变,任何人都可编辑。

在未锁定情况下仅显示「锁定」按钮,功能无变化:

当某个用户锁定后,会显示已锁定,并可通过菜单按钮解锁。此时只有该用户可以编辑此工作表字段:

如果工作表已被他人锁定,则可以通过按钮发送解锁请求消息给锁定者;如果是应用的拥有者,还可以强制解锁。注意,此时没有「保存」按钮,表单字段不可以被当前用户修改:

接收到解锁请求后,锁定者可以直接在应用消息里同意解锁,或者进入工作表编辑界面解锁:

在「强制解锁」时,需要考虑对方是否此时正在编辑该表。所以可以在用户开始编辑某个工作表时,记录该用户当前编辑该工作表状态为编辑中,当用户保存后「关闭」退出编辑时,清除编辑中状态。此时,在工作表编辑界面还可以增加「XXX 编辑中」的状态提示。

工作流中的锁定解锁的原型图如下:

二、为工作表和工作流增加「版本」功能。这样多人协作时,就能通过版本查看其他人修改的内容与备注,并且可以随时恢复到历史某个版本,避免误操作。

功能要点:

  1. 在保存工作表和发布工作流时,系统会自动保存一个版本;
  2. 用户可以手动创建版本,创建时可以给版本一个名称,这样方便查看;
  3. 用户可以恢复到历史记录中的某个版本;
  4. 用户可以导出单个工作表或工作流的某个版本,以便于导入其它应用或组织中做微量更新。

工作表的「版本历史」功能设计原型图如下,在工作表中新增一个 Tab 来展示历史版本。通过右上角的按钮创建新版本。

用户保存工作表表单或者设置时,都会自动创建一个版本,手动创建的版本(标题加粗的)有版本名称,表达的意义会更准确,方便查阅。

「操作」列有两个按钮,左边的是「恢复」按钮,可以使工作表恢复到某个历史版本。右边的按钮是「导出」当前工作表功能,同样导出 .mdy 文件(需要在导入时的逻辑做一定的调整,不再是单纯的新建应用,而可能是新增或更新应用中的某个工作表)。以下是导出原型图:

在「编辑字段」页,也可以把「保存」按钮升级成既可以保存又可以在保存时创建版本的按钮:

对于工作流,也增加一个「版本」页来把原来放在「历史」中的历史版本显示出来。可以通过按钮手动创建一个新版本(已发布时):

当工作流处于待更新发布时,将原来的「更新发布」按钮略做调整:

创建版本时,仍然需要输入版本名称:

同样的,单个工作流也是可以导出的:

三、为「应用」增加导出和导入「部分」工作表和工作流功能。这样可以变相解决应用分发升级包或者增值功能;也可以在一定程度上解决目前不得不在生产环境上升级搭建应用的困扰——复制一个应用出来,搭建好了导出新增和修改的部分再导入到生产环境应用即可。

导出功能的入口没有变化,仍然是在应用菜单中:

导出时,新增一个导出「指定应用项」的选项:

默认是导出全部,可以点击右边的按钮选择要导出的工作表、自定义页面或者工作流:

选择好了之后,就可以导出应用的指定部分了(导出格式仍然为 .mdy)。导出时,应该包含被导出工作表、自定义页面、工作流的最新版本:

在导入时,为了和导入整个应用有所区分(毕竟导出文件都是 .mdy,但处理的逻辑很不一样),入口做到应用的菜单里:

后续的原型我没有画了,这里总结一下我理解的在导入更新时需要注意的几点:

  1. 导入后,应该在目标应用的对应工作表、自定义页面、工作流写入一个新的版本;
  2. 导入工作表时,目标工作表的字段编辑可以完全覆盖,但表单设置里的「功能开关」不应该被覆盖,「自定义动作」和「打印模板」也应该只做新增,不做覆盖和删除;
  3. 导入工作表时,目标工作表已有的视图、筛选、统计、讨论、文件、日志不应该被覆盖或删除(只做新增),如果字段有修改会导致某些配置失效,应该自动更新这些配置(例如用于排序的字段被删除了,那视图里的排序也应该删除);
  4. 导入工作表时,目标应用的用户角色、权限也不应该被覆盖或删除,应参照变化更新字段变动带来的变动;
  5. 导入自定义页面和工作流时,直接完全覆盖。
四、仿照 Git ,为应用增加「创建分支」、「分支合并」等一系列功能,并且最终可以基于分支创建「应用升级包」,甚至伙伴在发布应用到应用库时,可以把不同的分支作为包含不同功能的应用发布。

这个功能从实现上来讲,比较复杂,首先,它是基于版本控制的,其次,要解决冲突,这里的逻辑比较麻烦,好在可以抄 Git 的思路。但另一方面,从用户角度出发,它也可以很简单。

首先,我们设计一个「创建分支应用」的功能。

分支应用不是普通的应用复制,而是和主应用有关联,所以创建好的分支应用在 UI 上有一些区别,表明了它是来自哪一个应用。当然,分支应用自己的名称和图标都是可以修改的:

分支应用和主应用、其它分支应用之间,可以通过拉取、合并等等动作将应用的功能合并,也可以以它和主应用、其它分支应用的区别,生成对应的应用升级包,方便应用分发:

这里面的细节还比较多,后面的原型图我就不画了,有兴趣的我们可以再交流。我一直对 Phil 之前提出的「应用插件」的想法比较感兴趣,也许是一个对明道云来说更完善更优雅的方案,希望有机会可以交流。今天的帖子也是提供一个思路,如果对明道云团队有一点点启发,就功德圆满了。这个产品用起来太爽了,忍不住想要做一些自己力所能及的贡献。

最后的最后,有个小请求,看能不能实现一下。在发布应用时,需要从自己已有的应用里选择一个发布。比较尴尬的是,我想发布到应用库时,由于我是在本地部署的服务器上搭建的应用,又没有购买专业版,所以没有导入 .mdy 文件的权限,这样我的本地应用根本到不了线上。所以,在没有购买专业版的情况下,是否可以增加在发布时可以上传 .mdy 文件?