本文讨论了二次开发项目从开发到上线的部署流程管理问题。强调需严格分离开发、测试、正式环境,并通过部署包规范安装测试,避免混乱和成果丢失。提出开发环境应更新最新内容,制作可靠部署包;禁止反向安装测试、正式环境改动到开发环境;设置统一的开发商标识以区分环境;利用解决方案管理二开内容,便于版本管理和问题追踪。最后提供了历史开发环境重建的小技巧。
一个需要二开的项目,从项目开始到成功上线,所经过的周期会比较长。在此过程中,会时刻面临着如何把二开成果部署到测试环境、正式环境的问题。
此问题非常重要!!!
如果没有规范,毫无章法的处理,则会让开发混乱,成果碎片化,并莫名丢失内容等。
为避免上述问题,提升开发效率,顺利的把二开成果,应用到正式环境,建议在整个二开过程中,遵循如下的原则,规范部署行为:
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'
推荐阅读