version-control - 使用 Siebel CRM 的推荐开发实践？

Question

我可能很快就会使用 Siebel CRM，我正在寻找有关使用现代开发实践和企业最佳实践的建议。

具体而言，我希望获得以下方面的建议:

• 我们应该如何设置版本控制(特别是使用 Subversion)？我们的存储库应该有什么样的结构？我们应该如何处理分支和标签？
• 我们如何进行代码审查？我们如何才能对通过 Siebel Tools 进行的不一定具有任何“代码”的配置更改进行同行评审？我们希望审查这些变更以确保质量和知识转移，并遵守变更管理政策。
• 哪种变更管理适合 Siebel？当我们进行新部署时，我们如何验证只有更改日志中列出的内容确实发生了更改？
• 我们如何自动测试我们的应用程序？使用 Siebel 甚至可以进行单元测试吗？我看到另一个建议使用 QTP 进行网络测试的问题，但还有其他可行的选择吗？
• 我们是否可以做其他事情来通过我们的 Siebel 开发工作实现持续集成实践？
• 对于命名约定和传统上属于“编码风格”准则的其他内容，您有什么建议？
• 我们应该如何区分开发角色和 Siebel 管理员角色？我们的构建/测试/部署周期应该是什么样的？

我不太可能为此获得任何新的昂贵工具，但如果有付费工具可以提供非常高的投资返回率，请随时提及。

如果您在这些方面有其他建议，但我的问题中没有具体解决，请随时添加。

Answer 1

How should we set up version control (specifically with Subversion)?

使用 Siebel Tools 文档中提供的指南。但请注意，Siebel 不是从 SVN 中的文件构建的，因此它只能用作归档工具；您无法管理您的代码或从 SVN 构建。

What kind of structure should our repository have? How should we handle branches and tags?

Siebel 开发代码不是在 SVN 中构建或管理的，因此这是一件非常无用的事情。只需记下您构建 SRF 和导出 Repo 的日期，并与 SVN 中的标签或分支相匹配。

How can we do code reviews? How can we peer review configuration changes made through Siebel Tools that don't necessarily have any "code"? We want to review these changes for quality assurance and knowledge transfer, as well as compliance with change management policies.

使用 Siebel 工具来执行此操作。它有一个针对明显错误的内置“检查”工具(所有开发人员在 checkin 之前都应该使用它)和一个差异工具(您需要检查同一对象的旧版本 - 您可以将其拖出 SVN如果你想)。我通常每天自动检查工具一次并查看输出日志，每天从 Siebel 服务器自动构建 5 次并在编译期间查找错误。通过 SVN 和标准差异工具进行差异可能是可能的，但 Siebel 对象在 SVN 中存储为类似 XML 的文件，因此有时难以阅读。

What sort of change management works well with Siebel? How do we verify that only things listed in our change log are actually changed when we do a new deploy?

?

How can we automate testing of our application? Is unit testing even possible with Siebel? I saw another question suggesting QTP for web testing, but are there other options that work?

QTP 是标准方法 - 在 Oracle 网站上查看他们可能推荐的其他供应商。您也可以试试 Sikuli。

Are there other things we can do to implement Continuous Integration practices with our Siebel development efforts?

不是真的。

What recommendations do you have for naming conventions and other things that would traditionally fall under "coding style" guidelines?

查看 Siebel Bookshelf 的相应部分以了解当前的命名指南并始终使用它们。

How should we separate development roles from Siebel Administrator roles?

不太清楚你的意思。

What should our build/test/deploy cycle look like?

每晚构建一个新的 SRF 并从 Dev 导出一个新的 Repo。 checkin 所有开发工作并完成单元测试后，将下一个 SRF 和 Repo 插入测试环境。此时在正常的软件开发中你会分支你的 SVN 并继续在主干上开发但是 Siebel 是不同的因为你不能从 SVN 构建并且你不能轻易地将大量文件从 SVN 恢复到你的构建环境中，所以你'最好在开发环境(并暂停主线开发开发直到完成)或测试环境中进行热修复，并对开发环境进行丑陋的反向移植(这实际上是大多数人所做的)。构建一个新的 SRF 并每晚从测试中导出一个新的 repo 协议(protocol)，一旦成功，就可以为您的生产版本创建一个副本。尽量坚持不超过 4 周的周期(1 周用于设计/原型(prototype)设计。1 周用于开发，1 周用于测试，1 周用于错误修复和部署)——如果超过这个时间，计划的开销就会变得太大太好了。

让生活更轻松的提示:避免在业务服务中使用 eScript(否则它变得难以管理)；使用所有 Siebel 内置工具，而不是自己动手；尽量避免任何汇总功能(这似乎总是一个好主意，但它总是会破坏性能)；将屏幕和 View 的数量保持在绝对最低限度；当您应该构建报告时不要构建 View ；始终确保 EIM 表与您所做的模式扩展相匹配——即使您现在不使用 EIM；尝试构建集成对象以匹配您的逻辑模式——它们总是有用的(对于 Web 服务、XML 发布)并且在事后构建是一项艰巨的工作；比运行时事件更喜欢工作流程规则；不要在没有索引的情况下添加新的排序或搜索规范——永远永远；不要通过引用链接到 LOV 表；总是打补丁；如果供应商没有说您可以做某事，则永远不要做。