Is it possible to have multiple items in the depot and yet have 1 "generic" job that can act upon those depot items?
May be I am not getting your terminology correct, but what do you mean "1 job that can act upon all depot items". I didn't understand what 'act' means here?
I guess my question is - What would be the purpose of this job?
Suppose I have many different versions and builds of MyApplication.msi in the depot, could a job be created that can execute msiexec /i against any of them? The "act" being the execution of msiexec with whatever options.
I believe that can be done.
1. Create a package with the installable msiexec file
2. Create Local Parameters in the package for all the options you want to use during run time. Look in the BladeLogic user guide on how to use local parameters in a package
3. Open the package and add an external command where you can define the following:
cd <directory where you deploy msiexec file>
msiexec /i /<version> /<build_number> (and all other options you want to use)
4. Replace all the variable options in the above command with the local parameters you created in the package
5. Create a deploy job. The local parameters you created will be available for population during run time in the deploy job
Naveen, are you saying to add the .msi as a file, not as software/msi package, and then create a BLpackage from that?
Maybe I wasn't clear on the original problem description, but when I mention version & build in the original post here, I'm not referring to arguments to the installer. There are multiple versions/builds of the same installer (MyProduct.msi) and each will eventually make it into the depot (as a file or software package I'm not sure yet). The arguments are the same, the process is the same...everything is the same except the particular version/build of the installer being used.
If I'm following what you're proposing, I would need to create a BLpackage per each installer that is added to the depot and create a job for each one of those. Maybe that is the correct, or only, way to do something like this with BBSA. It would be great if there was one job that could be used for all of those depot items.
Has anyone else encountered a similar situation? I would be interested in hearing how others have used BBSA in an agile development environment.
1 of 1 people found this helpful
I had a similar requirement for some of our Developers.
I have two packages, one that checks the application out of our CVS repository and another that deploys the application.
There is 1 parameter (the version number to be deployed) in both packages.
The way we did this:
Batch Job contains of three jobs
Job 1. Mounts a Network Share as RW and checks out the application release. - Executes against our Dev server.
Job 2. Mounts the Network Share as RO on target hosts, deploys application.
Job 3. Mounts the Network Share RW, deletes contents.
Of course this requires some method of sharing files between PROD/UAT and DEV, which took some work due to our security requirements.
1 of 1 people found this helpful
How are you creating the package objects? If you are auto-creating them, why not auto-create your jobs as well? if you are pushing to different environments won’t the server targets be different? So they you’d be constantly changing those around? 1 job per build also makes it clear which build you are pushing w/o having to open up the job and check.
That is where I was heading next actually, Bill. We're auto adding the depot items, so I plan to expand that to create the job as well. I am probably going to store off the job ID (not the key since it changes with versioning) relative to a particular installer and version+build combination. Also looks like I will need to store off the path, or group name, of the job also since you need both to get a job DBKey in BLCLI.
As far as handling the "moving targets", I've been tinkering with generating an execution task with the proper targets from the job using the BLCLI. Generate this with some unique name that includes the original job name. The one thing I ran into with the BLCLI is that the ExecutionTask class does not contain a method for deleting an execution task, although you can create them. In most other classes, I see you can create and delete them (DeployJob, NSHScriptJob).
The above is all conceptual at the moment as I'm still in the development stages of this. I will be happy to describe things in more detail after I have them working for real, so I'll keep this discussion open for the time being. I still would like to hear other peoples ideas in regards to this situation with agile development use of BBSA.
Thanks for the feedback naveen_anne, barrymcq & Bill Robinson.
there are unreleased commands you should look at:
you can also use the 'auto_generated' property and the datbase cleanup policies to handle the object sprawl.
That's great! How would I go about finding more information on these and other unreleased commands? I found http://communities.bmc.com/communities/docs/DOC-8922 which describes how to generate the unreleased blcli command documentation. Not quite the same paths with 8.1 though on windows:
Run %InstallationPath%\Bladelogic\8.1\NSH\blcli-generate-html.bat with the appropriate arguments to the 'xml' folder (%InstallationPath%\Bladelogic\8.1\NSH\br\xml) and a path to where the output is generated to.
The 'blcli-browse.bat' is very helpful too.
There’s a “document” in the scripting forum that discusses this.
RFE QM001695944 has been filed for this issue. You can track its progress in the support page.