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

Question

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

具体来说，我想就以下方面提出建议：

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

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

如果您有其他类似的建议，但我的一个问题没有具体解决，请随时添加。

Answer 1

SVN/CVS 不适合 Siebel，有几个原因
a) Siebel 对象是 db 对象，SVN/CVS 等存储 sif 等价的更改。
除了一些基本查询外，这些更改是无法查询的。
b) Siebel 工具和 SVN 之间的集成是松散耦合的集成。
理想的集成应该是与 Siebel 存储库和个人工具。

看看我们的工具 Object Hive，它解决了基于文件的版本控制的许多缺点。
http://www.enterprisebeacon.com/siebel_version_control_tool.html
Object Hive 专为 Siebel 版本控制而设计，它的一些功能包括：
1) 基于对象的存储库，类似于存储所有版本历史记录的 Siebel 存储库。
这使得查询更改和根据更改进行代码审查非常容易
2) 基于浏览器的 GUI，类似于 Siebel 工具，用于查询版本历史记录（无需合并 sif 文件进行更改）。
3) 无缝集成 - 直接与 Siebel 存储库集成。
个人开发人员没有凌乱的安装。 4) 强大的报告（实时和批量），可轻松识别任何时间段内的变化。
5) Oracle Exa-ready 认证。

Answer 2

我们已经为我们的 Siebel 系统建立了一个完整的持续集成工具链，其中包括 Subversion、Hudson、Jira、Siebel ADM 和一些集成所有内容的自行编写的东西。

这很有帮助，尽管 Siebel “源代码”不像某些基于 Java 的项目那样适合标准 CI 方法。

而且，是的，可以将您的文件（包括 SIF）放入您的 Subversion 存储库，并将其用作部署的源。

我正计划在http://siebel-ci.blogspot.de/ 上写博客 - 请继续关注。

Answer 3

我们应该如何设置版本控制（特别是 Subversion）？

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

我们的存储库应该有什么样的结构？我们应该如何处理分支和标签？

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

我们如何进行代码审查？我们如何对通过 Siebel Tools 所做的不一定有任何“代码”的配置更改进行同行评审？我们希望审查这些变更，以确保质量保证和知识转移，以及遵守变更管理政策。

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

什么样的变更管理适用于 Siebel？当我们进行新的部署时，我们如何验证只有更改日志中列出的内容实际发生了更改？

?

我们如何自动测试我们的应用程序？甚至可以使用 Siebel 进行单元测试吗？我看到另一个建议使用 QTP 进行 Web 测试的问题，但是还有其他可行的选项吗？

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

我们是否可以通过 Siebel 开发工作来实施持续集成实践？

不是真的。

对于命名约定和其他传统上属于“编码风格”准则的内容，您有什么建议？

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

我们应该如何区分开发角色和 Siebel 管理员角色？

不知道你的意思。

我们的构建/测试/部署周期应该是什么样的？

每晚构建一个新的 SRF 并从 Dev 导出一个新的 Repo。签入所有开发工作并完成单元测试后，获取下一个 SRF 和 Repo 并推送到测试环境中。此时，在正常的软件开发中，您将分支您的 SVN 并继续在主干上开发，但 Siebel 不同，因为您无法从 SVN 构建，并且您无法轻松地将大量文件从 SVN 恢复到您的构建环境中，所以您最好在开发中（并在完成之前暂停主线开发开发）或在测试环境中为测试进行热修复，并对开发环境进行丑陋的反向移植（实际上这是大多数人所做的）。构建一个新的 SRF 并从测试中导出一个新的存储库，每晚一次，一旦好了，为您的生产版本快照一份副本。 尽量坚持不超过 4 周的周期（1 周用于设计/原型设计。1 周用于开发，1 周用于测试，1 周用于错误修复和部署）——再长一点，规划的开销也会变得太大很棒。

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