11 replies to this topic

[Erl Briggs]

By Concurrent/Parallel Development, I mean do you have two or more code sets where development takes place on the the same function at the same time and is then brought back together in the Operational Acceptance or Live system.

Our Business has asked for the ability for two separate projects, with different (but similar) time lines, to be able to change a function, and do the associated testing, on ONLY that projects changes???

In effect they are asking for concurrent development to be implemented, but all I can see are problems, How do you 'merge' the developments back together? How do you keep the different development environments in sync?

Does anyone do Concurrent Development?
If so how? If Not, can you see how it would work?

Any help or insight would be much appreciated.
Cheers,
Erl.

[Rob Donovan]

Hi,

The last place I worked at, we wrote a system for 'locking' a function to a certain person/project and keeping track of all functions changed for a certain project.

We also developed quite a few tools for analysing functions in certain releases etc and getting back different versions.

We developed in a single account, with multiple projects.

It was a problem when the different projects needed the same functions, but we were always able to 'work around' it.

We also thought about trying to develop something to 'merge' functions together, but basically gave up cause it was not really possible.

I do know that quite a few people have written thier own development utils and release control software, but I have not heard of anything to 'merge' 2 functions together..

Rob D.

[Jeff Hon]

It's not really about merging two functions together. The problem here is version control of all application development objects, ie. Pro-IV functions/file defs, Oracle table defs, PL/SQL scripts etc.

At the previous company I worked for, there was a pretty nifty version control system installed on their UNIX development server. Each developer and tester could create their own dedicated development environment, ie. seperate software account and data set. When a piece of work was completed by a developer, it could be patched up to the tester's testing account and so forth. Having seperate development accounts ensured that there would be no function or file def locking between developers in the case of concurrent development.

All application objects were stored in a central library on the same server and developers would check them out or check them in when necessary. Each application object could be maintained as different versions, ie. 1.0.0, 1.0.1, 1.0.2 etc and each new version of a Pro-IV function would be tagged with the developer's comments and change reference.

[Rob Donovan]

Hi Jeff...

I dont like the 'lots of different' ProIV environment thing.

We have continued problems with Oracle Defs / ProIV Table Defs, code 1/2 in one system, invalid column names etc...

Unless there is very strict control around having multilple environments, it can become very messy and hard to maintain.

I much prefered the one system, we had alot less problems there.

The version control system is good, but again, it needs to be controled tightly, so that it does not just become a mess.

You could write functions in ProIV to control the version control system and build lists and do all the 'manual' work.

Rob D.

[hai]

Erl,

What Jeff suggested in good and has worked well in Sungard because it was strictly controlled and software releases were cut every 3 to 4 months by the resident librarian. That way everybody knew when to expect the next release and planned accordingly.

The version control tool used there was just the rcs freeware on Unix. There are better version control software out there such as cvs and Clearcase.

Merging code in Pro-IV seems like more trouble than it's worth. Concurrent development in Pro-IV is more about better code/project management.

Hai

[Rob Donovan]

Hi,

Just a note on the Version control etc, that 'Guest' bought up...

In my new editor (ProIV IDE), I am going to include methods of being able to incorporate hopefully ANY version control software into the editor.

This will allow each ProIV site to use what ever version control software that want.

Also, I can quite easily export a function/file/global logic etc into a flat file, that is comma separated. I'm not sure if that will also help people with version control and 'merging' things????

These things are not going be there from the first version, but I am coding with this sort of flexibility in mind.

I don't want to tie people down to using what I say

Rob D.

[Dan Shannon]

Rob's right in his approach - use one of the major open source tools. I'd suggest CVS which allows for multiple people to work concurrently on the same set of code (including on the same files) and then provides pointers when checking code in as to how to merge clashing changes into each other.

It would be simple enough to write a simple CVS handler for PRO-IV - you just need the bootstraps, a function to write out a PRO-IV function to a flat file (I'd say dump it to XML so there's a vague hope of human readability), a couple of functions to do CVS commands (update, edit, unedit, add, commit, checkout) and a function to read the XML back and re-build your PRO-IV environment.

Of course if this is how you set about it, then you'll need multiple PRO-IV development environments to work in. But I've done that before (one set of boots per person) and it works reasonably well, so long as you're exercising caution when upgrading.

[Erl Briggs]

This still begs the questions How do you keep the various environments in sync?

I'd expect that you'd have to retro fit all the changes from the different upgrades back into the other environments, then re-test anywhere that there is a functional conflict between two projects?

Is there anything that I'm missing?

[Rob Donovan]

Hi Dan,

It would be simple enough to write a simple CVS handler for PRO-IV - you just need the bootstraps, a function to write out a PRO-IV function to a flat file (I'd say dump it to XML so there's a vague hope of human readability), a couple of functions to do CVS commands (update, edit, unedit, add, commit, checkout) and a function to read the XML back and re-build your PRO-IV environment.

I have the CSV input/ outpt done, since this is how I get info back from the kernel for my editor. I'm just finishing off the send back to proiv (save). With this, I only send back the things that have changed and not the whole function to save on bandwidth and processing. Its very quick

Its all done through Bus & Tasks, no files. But I keep it in memory on the client side, and I am going to write a local save option so that you can save / load your modifications to your HD if the TCPIP connection fails and you cannot save... for safty

I opted not to use XML because this would have increased the bandwidth, and I didnt think that it would need to be 'read'. Should be able to mod it though to output via XML, fairly easilly.

Rob D.

[Dan Shannon]

Rob - you said 'CSV' - comma separated values - do you mean that or CVS (Concurrent Versioning System) (which is what I was on about)

Erl -

1. You'd often be surprised how few clashes there are in this sort of concurrent development, so many times it's not really a big issue.
2. There are 3 mechanisms within CVS to handle problems with concurrent development:
i) branching the source code allows for, for example, making point releases, setting off on a major dev project (the 'trunk') and branching off the installed code to allow for making minor changes, bug fixes etc. (the 'branch')
ii) You can set a 'watch' on whole code sets, or an individual piece of code, which makes CVS email interested users whenever another user checks a part of that code set for development. This gives you advance notice of who's attempting to make any changes that could result in a clash.
iii) Attempting to check in a piece of code that clashes with another concurrently made change will raise an error and ask you to resolve the differences before confirming that you want to overwrite the code.

With this in mind, it's usually possible to do what you're trying to do, albeit with some care and attention being needed when making changes to your code. But most people learn pretty quickly about the ideas behind the CVS concept, especially when faced with the 'use it (CVS) or lose it (the changes you made without using CVS)' issue.

Cheers

Dan Shannon

[Rob Donovan]

Oops,

Rob - you said 'CSV' - comma separated values - do you mean that or CVS (Concurrent Versioning System) (which is what I was on about)

Sorry, I thought you meant CSV

Rob D.