摘要由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'
推荐阅读