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