Recommended Development practices for working with Siebel CRM?

Question

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.

Answer 1

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

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.

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

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.

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.

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.

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 is the standard way to go - check on the Oracle web site for other vendors that they may recommend. You could also try Sikuli.

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

Not really.

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

Checkout the appropriate section of Siebel Bookshelf for current naming guidelines and use these always.

How should we separate development roles from Siebel Administrator roles?

Not sure what you mean.

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

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.

Answer 2

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.

Answer 3

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.