3 Replies Latest reply on Jan 17, 2012 1:50 PM by Bill Robinson

    versioning of files in the depot

      We have a process where we modify and publish a large xml used by Apache to route web calls to several Web servers.  Typically we backup the file, then modify it then push it out and issue a refresh command to apache.  Looking to automate this process and was wondering if there is a slick way to use BladeLogic to version the files for us?  Any suggestions would be appreciated

        • 1. versioning of files in the depot

          I'm not aware of any version control in BladeLogic, but then I'm not a product expert.


          Using my limted experience the way I might do it is that I would setup a SVN server and then in a bladelogic job you do a SVN checkout to the appserver.  Then you could setup the depot files to be 'live server objects' obtained from the SVN working dir on the BL appserver.


          This way you could check in any config changes from any dev box into the svn server and whenever the BL job ran the SVN update would pull down the latest copy to the app server and the depot live server object would be the most recent version.  You could have another job that didn't perform the checkout step so that you could manualy revert the working copy to any revision if required.


          Just one way, but I would wait for others who are far more experienced in the product than I to respond




          • 2. versioning of files in the depot

            The solution proposed in the post above is the kind of thing I have seen being in use.

            Most of the times what I have seen is that you will need to have versioning handled by the source control/version control tool like SVN, clearcase or CVS.

            There are scripts written which can run as NSH Scrpit jobs to checkout and checkin, which integrates with the Source control code.

            From their the script can call blcli commands/jython code to create a blpackage/custom software etc to push the file to the server and run any commands like the refresh apache command in  your case as post install or an external command in the blpackage.

            This way you can automate it. 

            Also, you can use Component template and blpackages created from that, you can go for auditing and snapshots as well.

            It is very good idea to parameterize such NSH Scripts/jobs and Component templates to make the solution well generic.




            • 3. versioning of files in the depot
              Bill Robinson

              everytime you create a new package w/ this file, that's effectively a new version.  there are versions of the package objects but they are not exposed to the user in any usable way.  eg you can't revert to V1 of a package if it's at V2.  or do any kind of diff between them.


              if you automate the package creation of the file then you could build in some versioning scheme into the package names.