11 Replies Latest reply on Feb 15, 2011 2:41 PM by Ryan Koziel

    Many depot items and 1 generic job?

      Share This:

      Hello - Is it possible to have multiple items in the depot and yet have 1 "generic" job that can act upon those depot items?


      The problem I am trying to solve is that we're going to leverage an instance of BBSA in the development/QA world in addition to production. In this development/QA instance we would like to "publish" each build of each application into the depot and would like to have 1 job that can act upon any of those depot items, since those are all similar in nature from an installation standpoint. Version and build selection would obviously need to be a part of that, but the fundamental problem is having 1 job that can act upon many similar depot items.


      We're using a 8.1 version of BBSA.


      Thanks in advance,


        • 1. Many depot items and 1 generic job?

          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?

          • 2. Many depot items and 1 generic 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.

            • 3. Many depot items and 1 generic job?

              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

              • 4. Re: Many depot items and 1 generic 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.

                • 5. Re: Many depot items and 1 generic job?

                  Hi Ryan,


                  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
                  • 6. Re: Many depot items and 1 generic job?
                    Bill Robinson

                    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.

                    1 of 1 people found this helpful
                    • 7. Re: Many depot items and 1 generic job?

                      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.

                      • 8. Re: Many depot items and 1 generic job?
                        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.

                        • 9. Re: Many depot items and 1 generic job?

                          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.

                          • 10. Re: Many depot items and 1 generic job?
                            Bill Robinson

                            There’s a “document” in the scripting forum that discusses this.

                            • 11. Re: Many depot items and 1 generic job?

                              RFE QM001695944 has been filed for this issue. You can track its progress in the support page.