开发流水线：低代码集成的最佳实践与案例

去年北京心玥软件公司帮朋友公司的李工梳理开发流水线时，他拍着桌子吐槽：“低代码应用集成简直是埋雷游戏，不提前想清楚准炸。”这话让我意识到，低代码集成这事儿，真得在开发早期就把问

低代码集成挑战，咱举个例子唠唠

给你们说个例子，就明白开发团队在低代码集成里会碰到啥主要难题了。

有家杂货店，想着开发个移动购物清单的应用。这主意最开始是营销部门想出来的，就为了优化顾客买杂货的体验。然后公司就用低代码工具开始搞这个应用的开发。

但是呢，这个购物清单应用可不是孤零零的。它得通过API连到公司的产品目录，这样用户就能搜产品，然后加到购物清单里。而且，应用还得把产品和特定门店的货架编号对应起来，方便用户按货架整理清单。可实现这个功能的API会时不时变，还没有版本控制。

另外，项目总监还想在预发布环境里测试这个工具。就这个例子来说，这里面有好几个集成点。API算一个，构建又是一个，而且构建说不定更关键。等营销部门把项目弄完了，得有人保证，就算周边软件一直变，这个应用还能顺顺当当运行。

低代码工具的集成点门道多

大多数CI/CD工具用的是那种简单的构建模式。像Jenkins或者CircleCI这种工具，它们在物理或者虚拟服务器上跑，这些服务器又跑在Linux或者Windows这些操作系统上。构建的时候呢，会从版本控制里把代码取出来，然后执行构建脚本。构建脚本会给操作系统返回0（代表成功）或者1（代表失败），还能往标准输出（STDOUT）或者标准错误（STDERR）写结果。这样工具就能把这个步骤标成红色（失败）或者绿色（成功），说不定还能显示点文本。要是脚本把测试结果生成文件了，构建后的步骤就能把这些结果和构建关联起来。

但这里面有个问题，好多低代码工具没有命令行运行器。就算有，可能也不适合要用的操作系统；就算适合，可能又没有签入、提交、同行评审和批准变更的机制。它们可能就只有个“保存”按钮。这就意味着，要是CI/CD触发构建，搞不好就把开发者最新还没测试的东西给弄进去了。

在选低代码工具之前，这些问题都得好好想想架构方面的事儿。要是低代码工具没有“代码提升”这个概念，最好弄个和主代码库分开的流水线。不过呢，低代码工具的流水线和API本身都能做做契约测试，就是得保证API能按预想的方式工作。要是API一变，购物清单应用不能用了，公司肯定得拦住不让这个软件发布。这就意味着契约测试在API和低代码工具这俩地方都得有。

有些低代码工具，像Mendix，确实有能访问构建的API，还有些有命令行接口。Canonic是个低代码后端即服务工具，它的低代码逻辑在GitHub里实现，支持代码评审、测试和拉取请求。用Canonic的时候，构建流水线能跟传统软件开发一样，先在本地跑，通过了再合并。

但大多数低代码工具把代码放在自己封闭的生态里，甚至还有自己的CI/CD平台。开发团队到最后可能会考虑选那种既能提供低代码工具，又有其他企业软件的供应商，像微软、甲骨文或者Salesforce。这样的话，说不定就能让它们俩无缝配合着运行。

集成测试和维护得这么干

就说回咱那个购物清单应用，这会儿有俩选择：要么从现有的CI/CD流水线调用低代码构建，要么单独维护一个构建流程。

不管选哪个，可能都得测测调用遗留软件里API的情况。这些API得有已知正确的响应。测试团队得写代码去调用API，这时候可以用API测试工具，像SoapUI或者Postman，也能用常用的编程语言写个小的自定义脚本。

Pytest是个基于Python的集成测试工具，能创建调用API的测试和脚本。要是团队对Python不熟或者不用Python，那就用其他熟悉的工具或者编程语言。最后还有个事儿得考虑，就是这些工具的密码和登录凭证，大多数API都得要这个，调用API的Python脚本也得知道。可以考虑用密钥管理应用来存这些信息，就跟处理其他企业软件的密码一样。

这些脚本写好了，还得有人维护。最合适干这个事儿的，一般是管传统CI/CD系统的团队，可能是DevOps团队、内部架构团队，或者一线编程团队。

就拿这个购物清单应用来说，这家公司没有专门的中央DevOps团队。开发团队自己负责支持自己搞的系统。营销团队把这个应用当一次性项目开发完了，项目总监可能会选产品搜索API团队来负责后面的构建维护，这可能是目前最好的选择。

有了这些思路，机灵点的团队在支持低代码项目的时候，能让发布和新代码同步，这样就能保证两个系统都靠谱。这就说明，提前做点准备，团队就能少遇到点低代码集成的麻烦。