phi*_*cou 4 testing version-control crm change-management siebel
我可能很快就会使用Siebel CRM,我正在寻找有关使用现代开发实践和企业最佳实践的建议.
具体来说,我想了解以下几个方面的建议:
我不太可能为此获得任何新的昂贵工具,但如果有一个付费工具可以提供非常好的投资回报率,请随意提及.
如果您有这些方面的其他建议,但我的一个问题没有明确解决,请随时添加.
我们应该如何设置版本控制(特别是使用Subversion)？
使用Siebel Tools文档中提供的指南.但请注意,Siebel不是从SVN中的文件构建的,因此它只能用作存档工具; 您无法管理您的代码或从SVN构建.
我们的存储库应该有什么样的结构？我们应该如何处理分支和标签？
Siebel开发代码不是在SVN中构建或管理的,因此这是一件非常无用的事情.只需记下您构建SRF并导出Repo并与SVN中的标记或分支匹配的日期.
我们如何进行代码审查？我们如何同行审查通过Siebel Tools进行的配置更改,这些更改不一定具有任何"代码"？我们希望审查这些变更,以确保质量和知识转移,以及遵守变更管理政策.
使用Siebel Tools执行此操作.它有一个内置的"检查"工具,用于明显的错误(所有开发人员应该在签入之前使用它)和一个diff工具(你需要检查同一个对象的旧版本 - 你可以拖出SVN如果你想).我通常每天一次自动化检查工具并查看输出日志,并且每天从Siebel服务器自动构建5次,并在编译期间查找错误.可以通过SVN和标准差异工具实现Diffs,但Siebel对象在SVN中存储为类似XML的文件,因此有时很难阅读.
哪种变更管理适用于Siebel？我们如何验证在进行新部署时,我们的更改日志中列出的内容是否只是实际更改了？
？
我们如何自动测试我们的应用程序？是否可以使用Siebel进行单元测试？我看到另一个问题建议用于网络测试的QTP,但还有其他选项吗？
QTP是标准的方法 - 在Oracle网站上查看他们可能推荐的其他供应商.你也可以尝试Sikuli.
我们可以通过Siebel开发工作实现持续集成实践吗？
并不是的.
您对命名约定和传统上属于"编码风格"指南的其他事项有什么建议？
查看Siebel Bookshelf的相应部分以获取当前的命名准则并始终使用它们.
我们应该如何将开发角色与Siebel管理员角色分开？
不明白你的意思.
我们的构建/测试/部署周期应该是什么样的？
建立一个新的SRF并每晚从Dev导出一个新的Repo.一旦完成所有开发工作并完成单元测试,请使用下一个SRF和Repo并进入测试环境.在正常的软件开发的这一点上,您将分支您的SVN并继续在主干上进行开发,但Siebel是不同的,因为您无法从SVN构建,并且您无法轻松地将大量文件从SVN恢复到您的构建环境中,因此您'最好在开发中进行测试的热修复(并在完成之前暂停主线开发)或在测试环境中进行测试,并对开发环境进行丑陋的反向移动(这实际上是大多数人所做的).建立一个新的SRF并每晚从Test中导出一个新的Repo,一旦这样做好,请为您的Production版本复制一份副本.
更轻松生活的提示:除了商业服务外,避免使用eScript(否则会变得无法管理); 使用所有Siebel内置工具而不是滚动自己的工具; 尽量避免任何累积功能(它似乎总是好主意,但它总是会破坏性能); 保持屏幕和视图的数量绝对最少; 当你应该建立报告时,不要建立视图; 始终确保EIM表与您所构建的架构扩展相匹配 - 即使您现在不使用EIM; 尝试构建集成对象以匹配您的逻辑架构 - 它们总是有用的(对于Web服务,XML发布)以及在事后构建的工作的地狱; 更喜欢工作流策略而不是运行时事件; 不要在没有索引的情况下添加新的排序或搜索规范 - 从来没有; 不要" t通过引用链接到LOV表; 永远补丁; 如果供应商没有说你可以做某事,那就不要这样做.
| 归档时间： |
|
| 查看次数： |
5758 次 |
| 最近记录： |