approaches for parallel development 
Author Message
 approaches for parallel development

I would be interested in hearing from Smalltalkers who have successfully
used ENVY to manage parallel development paths in the same library.  I
am faced with having to maintain two open editions of the same map along
with two open editions of most of the applications in the map.

I serve as the Library Supervisor for a project with about 30 active
developers in our library. While I used ENVY to maintain one path for
new development and a second carefully controlled path for maintenance
on deployed code, I  never used it for two active development paths.
Until now everyone on our project has been working on one software
release.  Recently, another development team merged with our initial
team.  The combined team is responsible for developing two different
releases of the same product.  For a variety of reasons we need keep the
functionality in the two releases separate even though both releases
will build on the same applications.  Eventually the code base for the
two projects will be merged.  However, we may need to follow separate
development paths for a few months.  We are working in one library since
both development efforts share a substantial common code base.  I would
welcome any suggestions on how I can keep things organized in the
library.

--
Michael Sayko



Wed, 18 Jun 1902 08:00:00 GMT  
 approaches for parallel development
Hi Michael,

You might want to take a look at this web page - http://c2.com/ppr/envy. It
has some ideas on how to partition your code.

Joe Herr



Wed, 18 Jun 1902 08:00:00 GMT  
 approaches for parallel development
First of all, you have my sympathy.  The situation you describe cannot be
made simple.  Manageable, perhaps, but not simple.  Whatever you decide to
do, developer training is crucial.  It can be real easy for people who don't
know what they're doing to make a mess that you will have to straighten out.

We do something similar to what you're describing, where we have one path
for maintenence, and one path for development.  Fixes/enhancements may need
to be migrated in either direction.

Basically, we have two separate config maps, one for each code stream.  Each
config map contains the same apps, just different versions/editions.  This
is clearer than two open editions of the same map, and is less prone to all
kinds of errors, i.e.,  mistakenly loading the wrong one, or releasing an
app to the wrong edition.  At the onset, we baselined each map and all their
contained apps/classes with different version name conventions, ie, R1.0 for
production and DEV1.0 for development.  This makes it easier to see what you
have loaded when in the Application manager.

Developers who need to be in both environments keep two images on their
workstations.  Instead of loading different maps, they startup the other
image.  In VW, you can change the UI look for one of the images as another
way of knowing which environment you're in.  Developers also need to keep a
list of classes/version numbers affected for each task/feature/bug fix.

So far, this process is working, although there is a lot of overhead.  The
key issues are trying to take advantage of the features of ENVY, rather than
re-inventing your own system, and not encumbering the developers too much.
I would also be very interested in hearing what others have to say on this
subject.

Ritchie Schacher

Quote:

> I would be interested in hearing from Smalltalkers who have successfully
> used ENVY to manage parallel development paths in the same library.  I
> am faced with having to maintain two open editions of the same map along
> with two open editions of most of the applications in the map.

> I serve as the Library Supervisor for a project with about 30 active
> developers in our library. While I used ENVY to maintain one path for
> new development and a second carefully controlled path for maintenance
> on deployed code, I  never used it for two active development paths.
> Until now everyone on our project has been working on one software
> release.  Recently, another development team merged with our initial
> team.  The combined team is responsible for developing two different
> releases of the same product.  For a variety of reasons we need keep the
> functionality in the two releases separate even though both releases
> will build on the same applications.  Eventually the code base for the
> two projects will be merged.  However, we may need to follow separate
> development paths for a few months.  We are working in one library since
> both development efforts share a substantial common code base.  I would
> welcome any suggestions on how I can keep things organized in the
> library.

> --
> Michael Sayko




Wed, 18 Jun 1902 08:00:00 GMT  
 approaches for parallel development
Michael,

ENVY works very well with multiple streams just as described in the
documentation.  It's not particularly difficult, simply establish a
baseline (by versioning off the apps and config maps) and then the two
development streams can go on their way.  Each stream should then
create new open editions of apps as appropriate and each stream should
have its own edition of the config maps.

The difficulty comes when it it is time to merge your changes back.
This is tedious work but Envy provides very good tools to analyze the
differences.  

A few tips:

- try to merge streams as often as is practical.  Don't let them get
too far apart.

- layer your software using applications and config maps.  Often
different streams or projects may share a lot of base code.  Try to
isolate the shared portions into separate config maps.

- keep your config maps up to date and make sure they are loadable.
This will allow you to move between streams.

- make liberal use of ENVY extensions.  Often you will have some key
classes which have a large amount of code, some of which is stable and
another portion which is changing.  The stable portions can be in one
defining application and the variable portions can be put in
extensions.

Good luck,
Mike

--
Michael J. McCloskey                             (613)-591-1600 x8542  
CrossKeys Systems Corporation                     Fax: (613)-599-2330



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Develop parallel program by functional approach

2. M2: A software development approach

3. Linguistic approaches to AI Linguistic Approaches to Artificial Intelligence

4. Linguistic approaches to AI Linguistic Approaches to Artificial Intelligence

5. ANNOUNCE: Parallel Applications Development Environment

6. ANNOUNCE: Parallel Applications Development Environment (PADE)

7. CFP: ACPC'96 - parallel DBs and parallel I/O

8. CFP: 3rd Int'l ACPC Conf: parallel DBS and parallel I/O

9. Parallel Lisps for Parallel Machines

10. Making parallel data less parallel, or serial

11. Serial-parallel and Parallel-serial converter

12. HELP: PARALLEL MACHINES AND PARALLEL LANGUAGES

 

 
Powered by phpBB® Forum Software