3 Replies Latest reply on Aug 3, 2005 2:35 PM by Michael Mraz

    Changing deployment target of a BLPackage via blcli

      Anyone know how to change the deployment target of a BLPackage via blcli?


      Let's say I have a bunch of files in /home/user/stuff and I need to package up all the files in the directory. How do deploy the files to /usr/stuff on the target servers?

        • 1. Re: Changing deployment target of a BLPackage via blcli

          This functionality is not yet supported and we have no plans to support it in the near future, so far as I know.


          What you can do is use a post-command on the deploy job to move the files from this directory to your desired directory.

          • 2. Re: Changing deployment target of a BLPackage via blcli

            I believe one of the reasons that editing BLPackages via BLCLI has been challenging is because BLPackages are XML-based (rather than DB-based).


            That being said, I imagine it'd be possible to use the BLCLI to return the location of the bldeploy.xml file from the file server. Then it would simply require some string-replacement operations on the XML file.


            Granted, this is very much a hack, so I'd be cautious approaching the problem with this sort of solution.

            • 3. Re: Changing deployment target of a BLPackage via blcli

              We regularly export BLPackages and modify the bldeploy.xml.


              We had the need to move over 100 file deploy jobs from our old server to a new one. Since exporting file deploys from 5.2.8 and importing them into 6.2 wasn't possible, we created file deploy packages for 1 to 6 files. Then we substituted capitalized template variables in all the fields in the xml file that corresponded to values that would differ from package to package such as name, source file and path. I then wrote a perl script to prompt the user for the values and generate a copy of the package with the appropriate number of file fields filled in. It performed substitutions on the bldeploy.xml in the copied template and we would then import the result. This was MUCH faster than invididually re-creating all the jobs.


              I'll sanitize the code and templates, roll it up into a tgz and submit it to the user contrib section of the knowledge base some time soon.


              Also, one of our Dev teams uses an exported BLPackage as a template for their application deployment releases. They simply substitute the newly compiled jar files for the appropriate resources in the package and update the bldeploy.xml as appropriate. The generated package is then checked into ClearCase and imported back into the CM. They only have to test the release/build instead of if the package build while maintaining use of the deployment functionality. It also allows us to use ClearCase as our repository, making the release immutable, instead of having to share packages between roles.


              Let me know if anyone wants more details on the process.