For a few years now there have been discussions on how Jade could be improved by including a new and modern take on source control, utilising industry accepted tools or ideas.
A vote here is firstly then to confirm you still feel this is important. Furthermore feel free to add comments, as it's a wide ranging topic so it's also about agreeing as a community what minimum viable functionality would be needed out of the gate, in order for you or your team to start using it.
Some thoughts below:
Recording changes, being able to:
- capture all changes made to an environment by a user, or set of users working on the same piece of work.
- take a snapshot of some changes (commit), recording along with it the user and a description
- selectively state which changes are in a given snapshot, along with the capability to undo or repair the last.
- select any existing snapshot, as the starting point for any new set of changes.
- understand what change set (branch?) you're currently on, and whether any changes have been made which have yet to be put into a snapshot.
Viewing/Editing snapshots, being able to:
- view all changes in a readable and consistent form (so without the environmental info & ddbs that have plagued existing extracts)
- merge any two snapshots easily. Where an edit is obvious, these would be automatically done by the system - or something external to it - with allowance for manual edits too
- view the history of an entity (rather than a change set)
Moving between snapshots, being able to:
- automatically apply code changes, initiate data transitions and run scripts where necessary to move to any existing snapshot defined in the system. Ideally complex changes such as renames and moves would be supported.
- where failures occur, provide a means where we can retry, or at the least, not be left stuck.
- provide an extract (scm/ddb/jcf equivalent) so another (eg test) environment could transition in the same manner.
Other, being able to
- allow for rule enforcement, so limiting who can load into an environment, or ensure that its not the same person who did the changes
- drive all commands via api/command-line, allowing for tasks to be driven by in-house or 3rd party tools.
- integrate with cloud tools, so as a community we could code share on github or the like (push/pull etc)
- extract the complete development history, so this could be imported into another environment (may get for free with cloud integration)
The ultimate end goal would be where the multi-user developer experience is maintained, so full support for two or more devs to work on independent changes in the same environment at the same time with as little friction as possible. It's likely that this would be non-trivial, but if implemented it would be a great step forward for the source control functionality and the product in general.
Murray Symon 22/11/2017 10:25:07 AM
Git integration is a vital requirement for our current toolset and processes. Jade is now the only thing we don't have in Git.
Delta360 21/10/2017 3:52:03 AM
Absolutely agree. Jade source control is inadequate for multi-developer environments.
Troy Fowles 9/10/2017 10:07:48 AM
Helpful point of reference to see how others are handling databases in source control systems?
John Beaufoy 29/09/2017 1:02:30 PM
@Ben ? thanks and totally agree - tried my best to be technology agnostic :-). My intent is not to define what is needed to be built into the Jade product, but rather define what we need when using the Jade product. The smartest changes to the product may be a combo of new APIs, UI extensions & cleaner extract format, so the wider community (Jade Plant certainly not excluded) can build out the remainder. This would then allow TFS integration or anything else.
Ben Butterfield 29/09/2017 1:48:55 AM
Very comprehensive post John. For me the biggest benefit would be to be able to use available source control solutions which have already solved many of the concurrent development problems we have. You mention git which is the clear industry favourite at the moment and I know you and your team have made progress in prototyping this. From a practical point of view we may also like TFS compatibility as it is already established here for our .net code, I'm hoping any solution would be available for both (and others if other people have established systems).