Source Control in Jade

[Jason]

I'm curious as to how people manage their Jade source code.

Other lanaguages that I'm familiar with are file based (e.g. C#, Java etc). This means you can use a source control system like Subversion or Team Foundation Server to store your source code, giving you benefits such as:

• Concurrent development: Multiple developers can change the same file concurrently, letting the source control resolve conflicts.
• Isolation: A developer makes their changes in their personal working copy, tests it and then commits to the repository. No one else is affected until the code is committed.
• Ability to revert changes to a known state: A developer can easily revert back to a known state if they need to (for example, if a refactoring excercise goes wrong a bug is introduced).
• Version history: The ability to see the history of a file or files.
• Branching: Allowing for R&D development, or supporting bug fixes for a release whilst working on the next version.
• Continuous Integration: CI systems such as Cruise Control work out of the box with source control systems.

As Jade code is stored in a database, it appears that it would be difficult to use a source control system. Therefore, what does everyone else do to address the things I've listed above?

[allistar]

Hi Jason,
I have seen three types of source control as applied to medium size (5 to 20 developers) JADE development teams:

1) Use JADE deltas for isolating source code changes to a particular developer (or developers). The downside here is that you cannot isolate structural (including JADE form) changes in a single development system using this approach. I have worked at companies where they have a "class locking" system which insists that yo must "lock" the class before changing it, and you cannot lock it is someone else has. This can be enforced by using a development security dll. Extracts for the changes made can then be automatically made and automatically applied to a known, sane test system for purposes of UAT.

2) Have a single "master" development environment and then each developer (or more likely the developers who share a common project) use a copy of that system for their development. At the end of development (and subsequent peer review) those changes are then moved to a master development environment. In my opinion this is error prone and cumbersome and isn't really "source control" as we know it.

3) Use of a development security library to track changes (and prevent changes, where required). The information collection from this can then automatically create patches and apply those patches to other systems (DEV2, UAT, PROD etc). This is an effective way of doing things but the largest downside is the toolkit needs to be developed and the effort to do so, while not immense, is never the less non trivial.

If you use Jade patch versioning, then source history can be maintained (so you can tell what a method looked like in prior versions).

Something you didn't mention is deployment. I would base any source control and testing strategy around the deployment strategy. One can't be considered without considering the impact on the other. If you are deploying to a single JADE database the deployment issue isn't as crucial, but if you're deploying to 1500 databases (and you value being able to easily upgrade those databases), then deployment becomes a major factor in any source control system.

Cheers,
Allistar.

[Jason]

Thanks Alistar. I'm not too worried about deployment at the moment - my question is more about developer productivity. Of the options you presented, option 3 seems to be the best in that regard. However, it sounds like that is still missing some of the benefits I listed in my opening post (e.g. isolation, ability to revert to a known state easily). Is that correct or have I misunderstood you?

As Jade has the ability to extract code from the database to files, I've sometimes wondered whether it would be feasible for developers to develop on a local copy of Jade and have some process to extract their changes to file which could then be committed to a source control repository. You'd need some way to update your local copy from the repository as well. Has anyone tried anything like this?

[alanvl]

One approach I developed was to post daily changes to Subversion. This was setup to run automatically after close of business.

This is done using patch versioning - identify changes within active patches for the extract period. The specific affected classes were extracted into a schema named directory structure.

Also see "Extracting Schemas in Sections" in the Jade user guide - use this for your baseline

The standard svn commit functionality was invoked in batch mode over the schema directories to load the changes.

Jade also provides a "Rejoining Sections of an Extracted Schema" function that could be run over a directory that was restored via a svn update

[Jason]

I've had a quick play with extracting schemas in sections but I couldn't quite get it to work as I wanted (though I can't quite remember the problem I had now).

I think Alistar's third suggestion, combined with developers working on local copies of Jade and extracting schemas in sections might be what I'm after.

Thanks for your suggestions. If I'm able to get something working I'll share it on here in case others find it useful.