Re: I use Git

I’m in a similar situation.  I had Cloverleaf tossed in my lap after our guru retired.  Since the guru pretty much did everything for everybody, he didn’t bother much with VC.  I learned that the Cloverleaf product offers VC and I expect to leverage it in another few months or so, once I figure it out.  But I wanted to start tracking changes immediately, so I started using what I know, and that’s Git.

My AIX admins declined my request to install Git on our TEST or PROD servers.  So I created three repositories on my local workstation: one for external programs that run outside (but interact with) Cloverleaf; one for tracking the configuration scripts (mostly shell scripts); and one for the Cloverleaf source.  I found that PROD and TEST were hopelessly out of sync.  So I only officially track PROD.  For my Cloverleaf source, I created a site directory with subdirectories for Tables, Xlate, formats, java_uccs, and tclprocs.  I also track the NetConfig files for each production site, naming them NetConfig.1, NetConfig.2, etc, to keep them apart.

This is only production.  When someone wants to start an enhancement, I copy the relevant Cloverleaf source from my Git working copy to the Cloverleaf TEST so they know they are starting from what is currently in PROD (and not some version on TEST that someone changed and then abandoned).  After development and testing has completed in TEST, and we’re ready for a PROD promotion, I copy the changed files back onto my workstation and commit them into Git.  I promote them from my workstation, not from TEST.  All NetConfig changes are done manually on PROD (not copied from TEST).  If, after a day or so, no disaster occurs in PROD, I tag the PROD promotion in Git.  Rinse and repeat.

Note that I am the only one using Git in all this.  Everyone else is oblivious.  This is all a temporary stop-gap until I get my head around the Cloverleaf development lifecycle which includes many tools such as version control and BOX for packaging/promotion.

I initially shared the concern about the Cloverleaf checkout locks.  However, as I learn more about the Cloverleaf development model, I feel that in this context the locks make more sense.  A Cloverleaf developer never has a private working copy of the code.  Rather, the client is working with code real-time fetched from a Cloverleaf TEST server.  If lack of communication leads two developers to change the same file at the same time, somebody is going to get hurt.  In this case, the lock mechanism compensates for the negligence of the technical team lead that should be communicating properly as to who should be changing what.

As Rob pointed out on a previous post, an admin can release abandoned locks.

I love Git.  I use it all the time for my open source projects.  The biggest problems I have with Git at work are that (1) none of my admins are willing to install/support it and (2) none of my colleagues are willing to effectively learn it.  The worst are my otherwise-bright colleagues with previous VC experience (baggage) who simply try to map the commands from CVS/SVN/ClearCase/whatever to Git and just make a mess that I have to fix.  Most Cloverleaf developers I’ve met that are not Tcl developers don’t possess the sophistication to make a distributed version control system (or even CVS/SVN) a regular part of their routine.  They’re terrified of command line VC.  That’s why I don’t see Git as a long term solution for Cloverleaf VC.  For most Cloverleaf developers at my work location, a GUI checkout, lock, change, check-in process makes more sense.  So once I get a grip on the Cloverleaf VC, I expect to drop Git and embrace the Cloverleaf model (at least for Cloverleaf source).  I expect to also reap the benefits of the BOX feature.

You specifically called out the challenge of tracking configuration scripts.  Unlike source code, configuration scripts often vary between TEST and PROD.  You can minimize this by externalizing these variations to property files and trying to make the TEST and PROD file systems as consistent as possible.  But fundamentally, the configuration of TEST and PROD will often be different due to different infrastructure topology if nothing else.  (IT shops have been addressing this for decades; but some in the industry have “discovered” this phenomenon under the guise of “DevOps”.)  In this vein, container-based cloud technology has garnered much attention.  (Docker containers, et al).  It would be interesting to see if Infor could offer cloud solutions with semi-private Docker repositories offering Cloverleaf Site images on which customers layer their own customizations.  Then the Docker image (or whatever container you prefer) becomes the unit of controlled deployment.