I’ve noticed, on a number of projects now, that Siebel Configuration, Release and Environments Management isn’t always at the top of project managers lists. This is especially true if the development work is behind schedule.
All of these areas are critical to the success of a Siebel project.
Configuration Management
The Repository based object control within Siebel is not ideal – not least due to the lack of any object versioning within the Repository tables or Siebel Tools. However, this doesn’t mean it is not possible to apply sensible and useful configuration management processes. For example:
- Version Control Integration
Siebel Tools does provide loose integration with version control systems via a batch file. I’ve used this, with a degree of success, with VSS, Subversion and CM Synergy to control object level SIF files. One programme I know even developed an automated build tool that would compile an SRF using specific build identified SIF files using task based work packages defined in CM Synergy. Note that configuration management plays a key role in managing the merge process, if you elect to maintain multiple code streams; for example, for long term change and short term emergency fix.
- Non Repository Version Control
Using ‘Export as XML’ or ADM will allow you to control and manage a large number of non-repository objects, such as Run Time Events, Personalisation, SmartScripts and so on. Client tools such as Tortoise SVN or CM Synergy allow these to be treated and managed as any other source code would be. Though clunky, I’ve also found manual ‘Release Notes’ to be a very useful tool in managing small releases of non-repository items. The release note can, and should, be used to tie the pieces together whether using VC integration or otherwise. That is, every release should be accompanied by a Release Note which details the steps, objects and versions required to build and deploy the release.
Environment Management
Having appropriate systems and environments in place to allow development, testing and release to Production is vital to delivering a project. This also plays a key role in the continued development and maintance of Siebel systems. Consider at least a development, system test and a ‘Production Like’ environment, in addition to Production, to allow for adequate unit, integration, UAT / OAT / PEN / Performance testing. For maintenance, you’ll want to consider a secondary development environment to support a parallel ‘emergency fix’ code stream, along with a seperate testing environment for this purpose. If you are implementing integration technologies across other systems, you may want to consider equivalent systems across environments for these too. It’s common, however, to share physical resources for the less performance critical systems in the environment. You will also want to set up automated nightly SRF builds and deployments in at least your main Development environment, while encouraging your developers to perform SRF refreshes and incremental Tools ‘gets’ first thing each morning.
Release Management
Siebel deployments range from simple reference data changes to full releases involving SRF, Repository, DDL, non-repository items, patch sets and infrastructure changes and upgrades. Do not underestimate the effort and risk involves in doing a release. The concepts described above feed directly into this, allowing you to prove your code release, be it a combination of SRF, Repository and Release Note, using the environments that you’ve flagged as your route to Production. Thoroughly unit tested code will mean nothing if you do not deploy the same code to the Production environment!
I’d be really interested to hear your stories or comments around your experience with managing Siebel code, especially from those who have implemented automated build and deployment toolsets.
