Selective extracts of new features and fault fixes for deplo

[ConvertFromOldNGs]

by Eric Peachey >> Sun, 15 Jul 2001 22:11:45 GMT

Hello,

Imagine you have about 8-10 developers actively building a Jade system (e.g. you have a number developing major new features as well as a small number involved in fixing faults that have been found during user testing). The client would like to pick and choose which new features and fault fixes are released into their test system. E.g. you may have fixed 15 faults but the client only wants 3 of them to be included in the release, and similarly they want just one of the new features but nothing else.

Keeping track of which classes and features have been added and/or modified is a bit of a problem to say the least. You may have the situation where a new property has been added to a class to support a fix that is to be released, but also some of its methods have been changed to accommodate other fixes that the client doesn't want this time round. There may be 7 - 10 days between releases so quite a lot of changes can be made to the system.

The patch versioning capability of Jade doesn't really help with this kind of thing. Keeping track of the changes manually would seem to be a significant overhead and exceptionally error prone. It's easy to imagine the problems that can be caused by missing things out, or of releasing new stuff which breaks existing functionality in the target system. Perhaps in the days of monolithic COBOL programs and relatively simple data structures things were a lot simpler. In any highly modular system (like any OO system) selective releases must always be problematic - or am I being overly negative? Perhaps there are some very smart version control systems out there that are integrated into OO development environments?

We have considered a number of options e.g. a) make a list of changes made as you go along; b) when you are working on a particular feature/fix add all the classes you have worked on into a 'view' to be extracted later; c) when working on a particular fix/feature log on to Jade with a unique userid that is linked somehow with the job you are doing. Of these we think the latter is probably the least useless idea. None of them are satisfactory.

Any ideas? How do you handle this kind of thing?

Cheers,

Eric in Dunedin

[ConvertFromOldNGs]

by Craig Shearer >> Mon, 16 Jul 2001 0:16:04 GMT

Hi Eric

I think you've summarised the difficulties well, and I don't see there's any easy solution to what you/we want to be able to do. So, you are really moving into new feature suggestion category here.

Basically, the ideal would be to be able to tell JADE you were working on a particular feature/bug fix, then have all your changes recorded against that thing. Then you could extract that, as a series of changes to be made to a target environment, and "replay" them against that environment. This would include any scripts that were required to be run, etc.

I see this as separate from the issue of "checking out classes" for changes. This would also be a valuable feature that would allow developers to ensure they were on conflicting with somebody else.

Ideas?

Craig.

[ConvertFromOldNGs]

by Phill >> Mon, 23 Jul 2001 22:49:40 GMT

Hi,

We are having the exact same problem over here in the UK. It's fine to say that releases/patches should be gathered together and released periodically at the same time, but in the REAL world of development, this is not always feasible.

We've only got 5 Jade developers at the moment, with another 21 in Linc, and if we 'Jet' our core system, we'd be looking at trying to control 26 Jade developers all working in the same schema at the same time (what a nightmare !).

There IS a requirement to allow developers to work on several faults / new features at the same time and not all of these can be released together. Even with new development in a schema that has ongoing maintenance, you can't always co-ordinate these releases, as priorities and clients requirements change.

The ability to assign work to a fault (similar to the 'delta' feature) but to include EVERYTHING that has been changed, including the addition of properties etc.. would be a great feature. Currently, we struggle using deltas as some items are not included, so we have to keep a 'manual' note of these and make sure we don't forget them when they go live. Not ideal, but just about manageable with only 5 developers.

I Don't know how anyone else manages when you start getting up to 8 - 10 developers all working in the same schema on different faults / enhancements, all going live at different times ??

Regards
Phill Hirst
Skipton Building Society

[ConvertFromOldNGs]

by Robert Barr >> Mon, 16 Jul 2001 3:09:26 GMT

Wot, no weather report, Eric?

Selective features - fine. But picking and choosing bug fixes?

Step back a bit and ask why does the customer want to make the already diffult lives of the developers even harder? Surely the coordination of developers and testers is a project management issue? Perhaps the
testers are trying to dodge doing regression testing? Whatever ... it sounds suspiciously like the tail is wagging the dog.

A developer will often go to a particular area of code to address a priority A fault, and while there, fix half a dozen lower priority faults. This is convenient because a) the developer is focussed on the complxities of the code area, and b) test data and processes need only
be set up once.
The overhead of tracking these as separate faults assigned to separate releases, is surely considerable?

[ConvertFromOldNGs]

by Stephen Persson >> Tue, 2 Oct 2001 1:39:26 GMT

Just to take this one step further....
Patch release or system release? How do you decide which is the most appropriate?

If a large number of changes have been made (which is how many anyway!?), how do you decide whether to release as a patch or a full extract. Likewise how many patches do you do before enoughs enoughs and decide its time for a full extract?

Secondly how do people do a full extract? Is the development environment treated as sacred and developers must be careful about what goes into it cause it could get loaded live - or do you let dev be a bit 'looser' and let developers try out things and play around a bit in dev without the worry that things could go live that shouldn't. If people prefer the later, where do you do the full extract from?

How are peolpe currently handling this?
Stephen Persson

[ConvertFromOldNGs]

by Stephen Persson >> Thu, 4 Oct 2001 1:14:21 GMT

Ohh C'mon..... Someone must have an opinion !?!
Or is it so speculative that no-one dares say anything!
I'm sure if I had 6 responses I'd probably have 6 different opinions, but surely there must be some sort of best practice involved with all this.

As for the development environment question, personally the thought of it turning into a sandpit/playground for developers scares the sweet batuties out of me - if the dev environment was getting quite different to production, I would start to get a tad concerned. But on the flip-side of the the coin, if you make developers take a singleUser copy of the system to try things out, it can become an absolute nightmare to try merge the systems again. Fine if you are working on a completely new class/form I suppose, otherwise it can end up being more trouble than its worth.

[ConvertFromOldNGs]

by Brett Greiner >> Thu, 4 Oct 2001 21:56:21 GMT

Hi Sippy,

Here's my 1 cents worth....

I've started looking at the Patch versioning that is provided by Jade. So far it seems a very good way of grouping modified code, on top of that add the Deltas, this is a good way of controlling code that is a 'work-in-progress' and the 'work-in-progress' code won't get released until it's checked in.

Brett Greiner
Kinetix.

[ConvertFromOldNGs]

by Craig Shearer >> Thu, 4 Oct 2001 3:43:21 GMT

Hi Stephen

OK, I'll venture an opinion.

Firstly, whether to do a full extract or a patch extract is basically a question of how long I want to wait doing the deploy, and how confident I am that everything I've changed will appear in the patch. Patch versioning is a new feature, so is likely to have some little inconsistencies (read bugs)... but when it does work, it's awefully convenient. So, for me at present, I tend to put small changes into patches, whereas large changes would tend to be full schema extracts - then I'm sure of getting everything, even if I am wasting time doing a full schema load.

On the second topic of what developers are allowed to do. Well, once a system is deployed, developers need to be more careful of what they do. All out refactoring of class hierarchies is next to impossible as you can't change a class's superclass in a deploy. So, developers have to be careful. Also, if there is a large amount of data in a deployed system, developers need to be careful of making changes that provoke lengthy reorgs. But apart from that, most stuff is fairly safe.

Having said that, I believe to be completely safe, it's always useful to have a sample copy of a deployed system that you can test a patch on before deploying it for real. That's how we operate things here. Given the existing support that JADE gives for deployment, this is about all you can do.

Craig.