为了解决系统实现与设计在持续迭代过程中的一致性等问题，BizWorks提供了一种代码与平台模型的双向联动机制。本文介绍BizWorks双向联动机制，以及如何使用BizWorks提供的相关能力，将代码与平台模型的双向联动顺畅融入到已有的研发流程中。
背景信息
由于产品的迭代交付周期、人员的组成、成员能力和职责分配等因素，研发团队的协作模式存在不同的风格，也会在团队成长过程中形成一些特有的团队默契和设计。BizWorks双向联动相关的功能点在模型设计、应用研发阶段都有涉及，您可以按需灵活搭配使用，能够适应不同团队的风格。而对于我们某一特定的团队或项目，通常希望能快速简单上手，形成一种行之有效的研发流程。
BizWorks双向联动机制概述
模型是对领域知识严格的组织，且有选择的抽象，是浓缩的知识。当然，只有其与实现之间具有紧密联系，才是有用的模型，否则就与代码的注释一样，“糟糕的注释，不如没有注释”。双向联动机制的直接能力就是保持迭代过程中模型和代码的紧密联系。
平台模型：BizWorks平台可以帮助我们设计、审查、分发、沉淀、演进企业数智化转型中的各类重要模型，模型自然是平台的核心之一。我们将沉淀到平台中的模型称为平台模型。
代码反映模型：遵照BWAF规范、通过平台生成的代码或通过人工识别标注关联的代码，代码实现也可以反映出其对应的模型。我们将代码中反映出来的模型称为代码反映模型，在IDEA插件中相对于平台模型，也简称代码反映模型为本地模型（研发人员本地代码反映出的模型）。
平台模型和代码的双向联动主要逻辑行为有代码生成、代码扫描、模型上报。在平台和IDE插件中分别有不同的操作与之对应。
双向联动研发流程
不区分角色权限的简单双向联动研发流程
简单流程考虑研发人员同时拥有模型和代码的操作权限，研发人员对自己实现业务所对应的代码与模型同时负责。在这种场景下，不严格区分模型设计角色或代码编写角色。简单双向联动研发流程如下图所示。
研发人员可以在流程中随时修改自己负责的代码和平台模型，通过BizWorks使其双向一致。您也可以选择发起代码评审，让更多的研发人员一起评审代码和模型设计。
上图中双向联动研发流程的详情如下：
应用创建，并绑定关联关系：BizWorks平台DevOps核心之一是应用，所以需要先创建应用。同时关联业务领域和商业能力。具体操作，请参见创建和管理中心应用。
脚手架生成：应用创建后，我们会以应用为维度组织代码。您可以选择关联已有仓库或创建新的仓库，然后通过平台的脚手架生成功能生成初始的代码脚手架。具体操作，请参见生成代码。
DDL脚本导出创建库表：除了代码脚手架的生成之外，我们也会借助DDL脚本导出快速创建好对应的库表。
拉出迭代开发分支：进入正常的迭代开发节奏，假设每个迭代会有特定的开发分支（或特定的Feature分支或其他分支，取决于我们的分支模型）。
Pull开发分支代码：以研发人员的视角，在本地Checkout出开发分支代码。
在本地开发：研发人员正常开发。
模型变更：在平台对模型进行变更，如添加字段、修改方法签名或新增模型等。
通过IDE插件同步模型信息到本地，进行实时一致性校验：IDE插件可以在同步平台模型信息后对代码反映模型进行对比校验。更多信息，请参见查看和调整BizWorks相关校验规则提示级别和触发检查和快速修复本地代码。
通过IDE插件增量生成，同步模型变更到本地代码：IDE插件可以直接将模型的变更同步到本地模型对应的代码上。具体操作，请参见同步平台模型到本地代码。
通过IDE插件标注代码为模型或创建新的模型：您也可以在本地通过标注或创建等方式修改已有模型，或新增模型。具体操作，请参见快速标记代码为模型和手动新建本地模型代码。
提交推送代码，按需发起代码评审：本地代码修改可以正常提交推送和代码评审。
通过IDE插件，快速提交代码中模型变更到平台：本地通过步骤11新增或修改的代码反映模型可以通过IDE插件快速扫描提交到平台。具体操作，请参见在Tool Window扫描本地模型。
通过以上步骤普通的平台模型的变更同步到代码，以及代码侧的变更上报到平台都已达成。接下来我们看一下数据模型的变动如何同步。
数据库调整：平台的数据模型调整，可通过步骤4修改库表（这个步骤可以从直接修改数据库开始）。
最新库表导入数据模型：通过BizWorks平台功能，将最新的库表导入数据模型。
按需调整关联：如果平台模型版本有变动，可以在应用平台的模型管理中关联最新的模型版本。
平台增量代码生成：数据模型目前需要通过平台的代码生成功能增量生成模型变动到代码中。增量生成的代码可以基于已有分支生成到新分支。新生成的分支会生成到代码仓库中，后续研发人员可以拉取新分支到本地，并选取其中需要的部分修改合并到开发中的分支。
步骤17之后，可以重复步骤6之后的流程，不断迭代修改代码和平台模型。
上述为研发阶段简单流程中平台模型和代码的双向联动流程。以上的流程介绍较为简单，主要是介绍一种可能的且较为普遍的双向联动流程。上述流程各个步骤之间的顺序也并非严格顺序，可以灵活组合。
引入角色权限区分的双向联动研发流程
在不区分角色权限的简单双向联动研发流程中，研发人员同时拥有模型和代码的操作权限，对代码和模型同时负责。但有些团队可能对研发人员有较为明确的角色区分，只有特定的负责人需要对平台模型设计和关键操作进行管控操作。因此，我们在简单流程的基础上引入权限区分。下图中绿色部分线条是需要有权限管控的操作，黑色的线条是不需权限管控的研发操作。
上图中的引入角色权限区分的双向联动研发流程与不区分角色权限的简单双向联动研发流程的区别详情如下：
步骤1~4无区别，步骤5由负责人创建好对应的迭代分支后，同时将迭代分支设为保护分支，只有迭代负责人有权限提交合并。
步骤6研发人员在本地拉取开发分支。
步骤7在开发分支基础上Checkout Feature分支或个人开发分支，并在本地开发。因为迭代的开发分支是设保护的，属于权限管控分支。研发人员需要在普通的分支上面开发，后续再通过代码评审后合并到权限管控的迭代开发分支上。
步骤9~11单向从平台同步平台模型信息到本地，对本地代码变更与不区分角色权限的简单双向联动研发流程并无区别。
步骤12提交推送代码并发起代码评审，此处的代码评审是必须的，迭代负责人需要对代码以及代码反映的模型进行审核。
步骤13代码审核，Pull开发分支最新代码，调整开发。在研发发起代码审核后，迭代负责人需要审核和调整。除了代码审核外，模型的审核负责人需要借助插件或平台扫描代码并与平台模型对比。如果需要修改调整则需要拉取代码到本地。
步骤14通过IDE插件双向同步，负责人可以将代码拉取到本地后借助IDE查看代码Diff，也可以借助IDE插件对代码和平台模型进行双向同步。因为负责人拥有模型修改权限，同步过程与不区分角色权限的简单双向联动研发流程没有区别，可以参考其步骤9~13。
步骤15~18为数据模型变动增量到代码，与不区分角色权限的简单双向联动研发流程并无区别。
上述流程中，对于代码和代码反映模型的变动需要有权限管控。
因为代码反映的模型和代码是一体的，所以借助代码的保护分支、代码评审、合并的权限管控机制，把代码反映模型变动后的模型上报的操作管控机制融入其中。没有权限的研发人员只可以单向同步平台模型到代码中。拥有权限的负责人在接受了代码合并后，再按照不区分角色权限的简单双向联动研发流程的上报机制把代码反映模型上报到平台，即完成了有权限区分下的双向联动。