after quite a while has passed since my last post, I'd like to go a step further. Judging from the number of site visits and a couple of PMs, there seems to be high interest in what we've achieved so far.
Unfortunately, since I'm not only in charge of Siebel deployments, but also of our Siebel project, and projects sometimes do not go too well, I had to re-prioritize my activities. My deep apologies to everyone who asked for information and got neglected promises only.
I'll at least try to deliver information in smaller chunks, thus being able to post more frequently.
Setting up Siebel ADM Framework
In our installation, Siebel Application Deployment Manager proved a valuable tool for automating deployments. If you've heard rumours about ADM framework being buggy or insufficient, chances are that you've heard them a long time ago.
In our experience, Siebel ADM framework does its job reasonably well, once set up properly, an can readily be extended if you've got standard Siebel expertise around.
A drawback of Siebel ADM framework is that you find only few experts worldwide who come with ready-to-use Siebel ADM framework know-how, so on many occasions you will have to proceed hands-on with Oracle's bookshelf.
Long story short: do not hesitate to use Siebel ADM framework, at least as of v8.1 - most of it requires only standard Siebel expertise, even though some of the pre-defined BCs might not be commonly known to all Siebel experts around.
So, in order to step forward towards Siebel Continuous Integration, the first thing to do is to set up a Siebel ADM framework environment. The best source of doing that is the Siebel Application Deployment Manager Guide, which can be found in Oracle's bookshelf here.
You should make yourself familiar with it - in my point of view, there is no way around this; you must know about it, otherwise it will not help you. So, if you are working in an SCM team which have not been in contact with Siebel before, you should make sure you get at least one guy with Siebel expertise for setting this up and getting it running.
Siebel ADM framework in general
The high-level architecure of Siebel ADM is shown in a nice chart in Oracle's bookshelf, reproduced here:
As you can see, you have four main components:
- a source environment, e.g. the staging environment where you do your development work
- one or many target environments, i.e. the environment(s) you want to deploy to
- an orchestration environment, i.e. Siebel ADM's core running the management server, and
- a client environment, merely a couple of batch scripts for controlling what the manager server should do
The basic idea of deploying some customization with the ADM framework is as follows:
- develop something in your source environment
- extract artifacts from the source environment, optionally committing them to a versioning system
- create and validate a deployable package with the ADM package utility (one of the tools in the client environment)
- use ADM command-line interface to control ADM deployments through the management server
- The input to the package utility basically consists of text-based files in a pre-defined directory structure. This lends itself extremely well to versioning, so what we did is to put all ADM-deployable artifacts into this directory structure and commit this to our versioning system. We then use the versioning system as input channel for the package utility, thus creating an ADM package from a particular version of these file. More about versioning in one of the subsequent posts, though.
- A given ADM package can be deployed to more than one environment, with the management server keeping track of what package was deployed where. With the help of management server, you should even be able to roll back to a previously deployed ADM package, a feature we have not tested thoroughly yet.
When you want to take advantage of the latter item, it is very important to make sure that each of your Siebel staging environments has an enterprise name different from the others, because this is the ID the management server uses for controlling where to deploy a package. If you cannot ensure this, you need an own orchestration environment per staging environment, which is obviously not what you really want.
However, before we started to use ADM framework, our Siebel systems where simply created by cloning virtual systems. This meant that the enterprise names of the environments where equal to each other, preventing us from using ADM framework the way it is meant to be used. We figured out, however, how to rename the enterprise of a Siebel environment without having to re-install it. Drop me a note or a comment if I should blog about this, too.
So far for the basics of ADM framework. If you are thinking about Siebel CI, to me it is a must to use it because it is the officially supported way to automate Siebel deployments.
Although there are many details to explain here, I think next time I'll blog about putting Siebel and Siebel ADM artifacts under version control, and why we stopped using the standard recommended script of integrating Siebel Tools and our versioning system Subversion.
Comments are welcome, as usual, as are PMs. Have fun.