Has anyone worked out a method for using version
control (RCS, CVS, etc) on the CM depot? Right now,
the depot is pretty much an unversioned mess with no
tracking of code/script revisions or user access. I
don't know what sort of hooks you could sink in CM to
automatically version, say, a script when opening and
editing from CM so I've been looking at performing an
hourly/daily/whatever crawl of the depot and doing a
checkin whenever something has changed. It's
exceedingly crude, won't catch every change, and I
won't be able to add meaningful comments, but it's
better than what exists now.
Is anyone else using a different strategy to manage
their script depot?
Thanks - Andy
Did anybody ever reply to this? I too am interested in version control for the depot.
Thank you in advance,
/me interested too :)
there is some amount of versioning in the product, but not at the level you want. this is going to have to be a feature request, open a support ticket for this.
What's stopping you from putting your files in the depot under the control of Subversion?
I mean, BladeLogic doesn't know/care if you make a change to the file in the depot. All it cares about is that it's named properly.
To illustrate this, I took one of my NSH scripts, then I modified it with vi, then I re-opened it. In the attached pics, you can see that BladeLogic doesn't make any complaints, event though the file is now different.
Of course, this is a security risk, as you can imagine, and it's one of the reasons you should restrict access to your depot. For example, someone could change one of your regularly scheduled scripts to do something malicious, and the only "paper trail" is on the file system itself (BladeLogic is oblivious to the change.)
This could encourage you to use Subversion, since it could tell you when the file was changed, and would give you an easy way to roll back.
Attached are three screen shots illustrating the process.
The first shows the file in BladeLogic, the second shows where I added the line HA HA I ADDED THIS WITH VI and the last shows the same changes in the GUI.
the only issues i'd see are:
-if you are editing the files in the CM GUI at all, then you may not get those changes to commit before you make another change.
-if you add files through svn the won't be registered in the db and won't show up in the gui, so you'll still have to add stuff through the gui.
it might be better (but not easier) to use the import/export blcli to suck all your scripts, etc out of bladelogic into svn and back.
but yeah - editing the files directly, even blpackage files on the depot works, though i would say it's not supported.
True - if you added them to the depot manually, they won't show up in the GUI.
If I were going to do this, I would create the script and the job in the GUI, then manage them via subversion from there on out. In other words, all future edits would have to be done outside of the BladeLogic depot.
Being able to do rollbacks would be nice, and this would also be a great way for multiple users to collaborate on shared scripts.
We have some monstrous nsh and jython scripts here, so I might bring this up with the team.
it's been brought up before, it would be useful to add the versioning into the product, or rather expose it (many of the objects are versioned), but it's always good for large customers to ask for things :)
I've got a start with a NSH script with basic time based version control on certain depot folders. If people are interesetd i can post it here.
But i think versioning integrated and/or some proper event driven hooks would be really usefull for the product.
This was one of the requirements which was not met during our PoC with BL.
I'll open a feauture request with support and try to get the ball rolling.