git for Cloverleaf?

[Stephan Rubin]

Hi There,

We recently had a kerfuffle on one of our other systems which stemmed from a key script not being properly synced between nodes in an HA environment. While this is neither here nor there, it got me and my group to thinking about ways which we could improve the quality, consistency, and reliability of our code. One area which was immediately identified as an opportunity for improvement was the implementation of version/source control for all of our key files (shell scripts, tcl procs, Xlates, NetConfig, etc.)

Presently, our version control is entirely manual, meaning we simply make backups of files as needed in the $SITEROOT/revisions directory. I probably don’t need to explain why this is a bad and untenable process.

As a former part-time web developer, a more savvy former peer of mine turned me onto his VCS of choice, git. Git was not in vogue when I was doing web work, but I wish it had been because it blows everything else I’ve seen out of the water in terms of speed, flexibility, reliability, and ease of use.

I want to investigate whether there’s a way we can implement git at our facility for both version control of files, as well as packaging and deployment of changes.  was hoping maybe some folks at other sites had experience in using git to control versions and source, as well as manage moving code between environments.

Thanks!

Topic

[Peter Heggie]

I’m hoping someone from Cloverleaf will respond to this topic, as I’ve heard there are some good things coming in the area of packaging and deployment. I don’t know if source / revision control is also being addressed, bt I hope so because I’ve focused on these things for many years and it is near and dear to my heart.

Peter Heggie

[Karl Garen]

I too am interested in this area.  Although I have never used git before a quick look at it looks promising.  

I have recently thought that one could maintain a separate “source” copy of the code using git perhaps as a way to ease into it / get comfortable with it without affecting the current “executable” of the cloverleaf code (xlate,tclprocs, etc.) which of course is also the source currently.     The NetConfig and hl7 variants would be tricky I think.

I hope to experiment with this in the near future.

Karl Garen
Sr. Programmer Analyst
University of Vermont Medical Center
Burlington, Vermont

[Stephan Rubin]

So I’ve done a little tinkering and a lot of brainstorming around this issue, and from a purely technical standpoint, I think there is a way facilities can implement a distributed Version Control System like git to track and control all engine files (yes, even the complicated ones like HL7 variants), as well as leverage git’s distributed architecture to make it a de facto deployment manager.

The problem we’ve always had with version control (and most people seem to have) is that, because the Cloverleaf IDE hooks directly into runtime files, any changes you make to any code happens right on your active stack; there’s no real ‘dev’ environment to speak of.

Because git is a distributed VCS though, it works by copying your entire codebase to each individual workstation, so, in the eyes of git, by default everyone’s workstation becomes a ‘dev’ environment.

This however runs counter to how Cloverleaf thinks about and treats its files, directories, and environments, which is that there is One Codebase To Rule Them All.

So the way around this would be to turn every workstation into a Cloverleaf ‘Server,’ install git on your servers and your workstations, make your Test and Production environments git repositories, then simply clone that repo to all your workstations. You then have remote repos (your Test and Prod servers) which all your workstations can push to, pull from, and fork as needed, meaning you can bundle up files which have changed as a result of work and commit them to either your test or Production environments with a single command (imagine a world where deploying an entire interface, XLates, tclprocs, HL7 variants and all, is as simple as typing ‘git commit.’ Anyone else just get goosebumps?) And since your workstation is a ‘Server’ in the eyes of Cloverleaf, you can hook the IDE right into those files and muck around with whatever you want without having to worry about a) breaking someone else’s lock, b) wrecking someone else’s code, or c) inadvertently busting up some other testing that’s going on somewhere else in the hospital that you know nothing about.

The gotcha here, of course, is that to turn your workstation into a server requires a server license from Cloverleaf, and I’m guessing most of you don’t have that sort of budgetary slack sitting there, just begging to be spent. And if you do, well then I would just love a new MacBook Air… inquire within for mailing address 🙂

From an architecture standpoint though, does this make sense? I formulated this in my head based my understanding of Cloverleaf and our specific architecture here at my hospital, but I’m just a man; does this resonate with any other facilities who maybe have different workflows?

[Author]

Replies