[Stephan Rubin]

Vaughn,

I too am interested in hearing about your SVN implementation, in particular because you mentioned that you have a single collaborator presently; I am wondering how you see the version and change control workflows you currently have in place scaling as your team grows? Change control becomes exponentially more important as the number of collaborators on a project increases.

Also, you made mention of automated testing you conduct… what sort of tools or framework are you using to carry this out?

[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