摘要由AI智能服务提供本文讨论了二开项目从开发到上线的周期较长，并强调了规范部署行为的重要性。提出了开发、测试、正式环境分离，通过部署包安装二开成果，禁止反向安装改动内容，慎重设置开发商标识，以及通过解决方案管理二开内容的建议。同时，还提供了修正已有问题和重建开发环境的方法。
一个需要二开的项目，从项目开始到成功上线，所经过的周期会比较长。在此过程中，会时刻面临着如何把二开成果部署到测试环境、正式环境的问题。
此问题非常重要！！！
如果没有规范，毫无章法的处理，则会让开发混乱，成果碎片化，并莫名丢失内容等。
为避免上述问题，提升开发效率，顺利的把二开成果，应用到正式环境，建议在整个二开过程中，遵循如下的原则，规范部署行为：
1. 开发环境、测试环境、正式环境必须分离：
首先，正式环境不允许直接开发！只能经过充分测试的二开成果，才允许部署到正式环境，被最终用户使用；
其次，通过构建正式部署包的方式，把二开成果，部署到独立的测试环境。既测试部署包的完整性，也测试功能的正确性；
而开发环境则主要用于开发、调整功能，是构建部署包的源头。
2. 二开成果，必须通过部署包，安装到测试环境、正式环境：
测试环境用于测试安装包的完整性以及二开功能的正确性。
发现问题后，需要在开发环境中修复，打包进下一个部署包验证。
如果正式环境中，发现了问题，为避免影响的用户使用，可以即时进行局部调整。但需要记录下来，回头在开发环境中手工同步调整。
通过这种方式确保开发环境的内容为最新的，制作的部署包是可靠的。
3. 不允许把测试环境、正式环境的改动的内容，制作成部署包，反向安装到开发环境：
二开的内容在安装到目标数据中心后，会自动标记一个安装包Id，标明此业务对象是部署而来，并非手工创建。
部分功能，可能会据此锁定业务对象，禁止用户修改。
如单据转换规则，在安装后，自动更新了安装包Id，会被认为是其他开发商的成果，在修改保存时，自动扩展一个新分支。
这会导致扩展分支原来越多，越来越深，难以控制。
[i]如果现场已经是这样的结果，请按照如下步骤修正：[/i]
a. 在开发环境删除此转换规则的全部扩展；
b. 对照正式环境的内容，在开发环境，重新配置，保存为一个完整的扩展；
c. 在开发环境制作部署包，包含此扩展；
d. 删除正式环境的全部扩展，执行安装包，同步二开内容；
特别说明：可能需要到后台数据库中删除扩展，删除前，请备份数据中心；
4. 慎重设置开发商标识：
每个数据中心，在登录K/3 Cloud BOS设计器之前，都需要设置开发商标识。
通过BOS设计器设计的业务对象，会自动记录下本数据中心的开发商标识。
二开成果部署到其他数据中心之后，如果开发商标识不同，不允许被修改。
那么开发环境、测试环境、正式环境的开发商标识是否要设置成一样的？
建议各开发环境，开发商标识保持一致，设置为二开伙伴的标识，如JSKD；
而测试环境与正式环境的开发商标识，则设置为客户的标识，如DM。
这样可以把伙伴二开成果与客户的局部小调整分隔开，避免部署二开成果时，覆盖了客户的局部小调整。
5. 通过解决方案，管理二开内容：
业务对象之间其实是有非常复杂的关联关系，并不是独立存在的。
如单据引用基础资料、单据转换规则依赖单据设计等。
通过解决方案，可以把二开的内容系统性的组织在一起。
在需要打包时，一键点击"构建"，即可把全部二开内容，打进一个完整的部署包。
既避免遗漏了二开内容，也非常便于进行二开成果版本管理、成果归档等。甚至在出现问题时，也非常容易重现环境，查找原因。
最后，介绍一个小技巧：
历史的开发环境已经没了，如何重新部署一个开发环境？
a. 新建一个空白的数据中心；
b. 设置开发商标识，与之前环境的开发商标识保持一致；
c. 安装部署包，部署二开成果；
d. 到后台数据库，找到 FSupplierName 为本开发商标识的转换规则，清空其FPackageId；
select FPACKAGEID from T_META_CONVERTRULE where FSUPPLIERNAME = 'JSKD'
推荐阅读