使用 Siebel CRM 的推荐开发实践？
我可能很快就会使用 Siebel CRM，并且正在寻求有关使用现代开发实践和企业最佳实践的建议。
具体来说，我想了解以下方面的建议：
- 我们应该如何设置版本控制（特别是 Subversion）？我们的存储库应该具有什么样的结构？我们应该如何处理分支和标签？
- 我们如何进行代码审查？我们如何对通过 Siebel Tools 进行的不一定有任何“代码”的配置更改进行同行评审？我们希望审查这些变更以确保质量保证和知识转移，以及遵守变更管理政策。
- 哪种变革管理适合 Siebel？当我们进行新的部署时，我们如何验证只有更改日志中列出的内容才真正发生更改？
- 我们如何自动化应用程序测试？使用 Siebel 是否可以进行单元测试？我看到另一个问题建议使用 QTP 进行网络测试，但是还有其他可行的选择吗？
- 我们还可以做其他事情来通过 Siebel 开发工作实施持续集成实践吗？
- 对于命名约定和其他传统上属于“编码风格”准则的内容，您有什么建议？
- 我们应该如何将开发角色与 Siebel 管理员角色分开？我们的构建/测试/部署周期应该是什么样的？
我不太可能为此获得任何新的昂贵工具，但如果有一个付费工具可以提供非常高的投资回报率，请随时提及。
如果您有类似的其他建议，但我的问题之一没有具体解决，请随时添加。
I may be working with Siebel CRM soon, and I'm looking for advice on using modern development practices and enterprise best practices.
Specifically I'd like advice on the following areas:
- How should we set up version control (specifically with Subversion)? What kind of structure should our repository have? How should we handle branches and tags?
- 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.
- 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?
- 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?
- How should we separate development roles from Siebel Administrator roles? What should our build/test/deploy cycle look like?
It's not likely that I'll be able to obtain any new expensive tools for this, but if there's a paid tool that provides really great ROI, feel free to mention it.
If you have other recommendations along these lines, but not specifically addressed by one of my questions, feel free to add that as well.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
使用 Siebel Tools 文档中提供的指南。但请注意，Siebel 不是从 SVN 中的文件构建的，因此它只能用作归档工具；您无法管理您的代码或从 SVN 进行构建。
Siebel 开发代码不是在 SVN 中构建或管理的，因此这是一件非常无用的事情。只需记下您构建 SRF 和导出 Repo 的日期，并与 SVN 中的标签或分支匹配即可。
使用 Siebel Tools 来执行此操作。它有一个内置的“检查”工具来检查明显的错误（所有开发人员都应该在签入之前使用它）和一个 diff 工具（您需要检查同一对象的旧版本 - 您可以将其从 SVN 中拖出）如果你想）。我通常每天自动执行一次检查工具并检查输出日志，每天从 Siebel 服务器自动构建 5 次，并在编译过程中查找错误。通过 SVN 和标准 diff 工具进行差异可能是可能的，但 Siebel 对象在 SVN 中存储为类似 XML 的文件，因此有时难以读取。
？
QTP 是标准方法 - 在 Oracle 网站上查看他们可能推荐的其他供应商。你也可以尝试西库利。
并不真地。
查看 Siebel Bookshelf 的相应部分以了解当前的命名指南并始终使用这些指南。
不确定你的意思。
每晚构建一个新的 SRF 并从 Dev 导出一个新的 Repo。签入所有开发工作并完成单元测试后，将下一个 SRF 和 Repo 推送到测试环境中。此时，在正常的软件开发中，您会分支 SVN 并继续在主干上开发，但 Siebel 不同，因为您无法从 SVN 构建，也无法轻松地将大量文件从 SVN 恢复到构建环境中，因此您'最好在开发中（并暂停主线开发开发直到完成）或在测试环境中对测试进行热修复，并对开发环境进行丑陋的向后移植（这实际上是大多数人所做的）。构建一个新的 SRF 并每晚从 Test 导出一个新的 Repo，一旦一切顺利，就为您的生产版本获取一个副本。
尽量坚持不超过 4 周的周期（1 周用于设计/原型设计。1 周用于开发，1 周用于测试，1 周用于错误修复和部署）——任何长于该周期的时间都会导致规划的开销过大伟大的。
更轻松生活的提示：除了商业服务之外，避免使用 eScript（否则它会变得难以管理）；使用所有 Siebel 内置工具，而不是自行构建；尝试避免任何汇总功能（这似乎总是一个好主意，但它总是会破坏性能）；将屏幕和视图的数量保持在绝对最低限度；当您应该构建报告时，不要构建视图；始终确保 EIM 表匹配以及您创建的架构扩展 - 即使您现在不使用 EIM；尝试构建集成对象来匹配您的逻辑模式 - 它们总是有用的（对于 Web 服务、XML 发布），但事后构建却是一项艰巨的工作；与运行时事件相比更喜欢工作流程策略；永远不要添加没有索引的新排序或搜索规范；不要通过引用链接到 LOV 表；总是打补丁；如果供应商没有说你可以做某事，就永远不要做。
use the guidance provided in the documentation for Siebel Tools. But please note that Siebel does not build from the files in SVN so it will only be useful as an archival tool; you cannot manage your code or build from SVN.
Siebel development code is not built or managed in SVN so this is a pretty useless thing to do. Just note the date that you built your SRF and exported your Repo and match with a tag or branch in SVN.
Use Siebel Tools to do this. It has a built in 'checking' tool for obvious errors (all devs should be using this before they check in) and a diff tool (you will need to check against an older version of the same object - which you could drag out of SVN if you want). I normally automate the checking tool once a day and review the output logs, and automate build from the Siebel server 5 times a day and look for errors during the compile. Diffs via SVN and a standard diff tool might be possible, but the Siebel objects are stored as XML-like files in SVN and so are hard to read sometimes.
?
QTP is the standard way to go - check on the Oracle web site for other vendors that they may recommend. You could also try Sikuli.
Not really.
Checkout the appropriate section of Siebel Bookshelf for current naming guidelines and use these always.
Not sure what you mean.
Build a new SRF and export a new Repo from Dev once a night. Once all the dev work has been checked-in and unit tests are done take the next SRF and Repo and push into the test environment. At this point in normal software development you'd branch your SVN and continue to develop on the trunk but Siebel is different because you cannot build from SVN and you cannot easily restore a whole lot of files from SVN into your build environment, so you're best to make hot fixes for test either in dev (and pause mainline dev development until that is done) or in the test environment, and do ugly backports to the development environment (that's what most people do in fact). Build a new SRF and export a new Repo from Test once a night and once that's good, snap a copy for your Production release.
Try to stick to cycles of no more than 4 weeks (1 week for desing/prototyping. 1 week for dev, 1 week for test, 1 week for bug fixes and deployment) - any longer than that and the overhead of planning will become too great.
Hints for an easier life: Avoid eScript except in Business Services (otherwise it becomes unmanageable); use all the Siebel built-in tools instead of rolling-your own; try to avoid any roll-up functionality (it always seems like a good idea but it always destroys performance); keep the number of screens and views to an absolute minimum; do not build views when you should be building reports instead; always make sure that EIM tables match and schema extensions that you make - even if you don't use EIM right now; try to build Integration Objects to match your logical schema - they are always useful (for web services, XML publishing) and a hell of a job to build after the fact; prefer Workflow Policies over run-time Events; don't add new sort or search specifications without indexes - ever ever ever; don't make by-reference links to the LOV table; always patch; if the vendor doesn't say that you can do something, never do it.
我们为 Siebel 系统建立了完整的持续集成工具链，包括 Subversion、Hudson、Jira、Siebel ADM 和一些自行编写的集成所有内容的工具链。
尽管 Siebel“源代码”不像某些基于 Java 的项目那样适合标准 CI 方法，但这还是有很大帮助的。
是的，您可以将您的文件（包括 SIF）放入您的 Subversion 存储库中，并将其用作部署的源。
我计划在 http://siebel-ci.blogspot.de/ 中发表有关此内容的博客 -敬请关注。
We have set up a complete Continuous Integration toolchain for our Siebel systems consisting of Subversion, Hudson, Jira, Siebel ADM and some self-written stuff integrating everything.
This helepd a lot, although Siebel "source code" is not as suitable for standard CI approaches as, say, some Java-based project.
And, YES, it is possible to put your files - including SIF - into your Subversion repository and use this as source for your deployments.
I'm planning to blog about this in http://siebel-ci.blogspot.de/ - stay tuned.
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 认证。
SVN/CVS are not suitable for Siebel, a few reasons being
a) Siebel objects are db objects and SVN/CVS etc store sif equivalent of the changes.
These changes are impossible to query except for some basic queries.
b) The integration between Siebel tools and SVN is a loosely coupled integration.
The ideal integration should be with the Siebel repository and invidual tools.
Take a look at our tool Object Hive it addresses many of the short comings of a files based version control.
http://www.enterprisebeacon.com/siebel_version_control_tool.html
Object Hive has been from the ground up specifically for Siebel version control, some of its features are:
1) Object Based repository similar to Siebel repository that stores all version history.
This makes is very easy to query changes and conduct code reviews based on the changes
2) A browser based GUI that is similar to Siebel tools to query for version history (no combing sif files for changes).
3) Seamless integration - directly integrates with the Siebel repository.
No messy installation for invidual developer.
4) Powerful reporting (realtime and batch) to easily identify changes over any time period.
5) Oracle Exa-ready certified.