Solved

Comment in managing Parallel Software Development In Different Location?

Posted on 2007-11-22
15
231 Views
Last Modified: 2013-11-13
There's no correct answer for my question, but i need some experts comment on this.
We are planning for a parallel development environment for 1 product(or source code) in 2 totally independent development team located in different region serving different requests.

Because the 2 teams are totally independent, they are not restricted by each other or controlled by the same management, what is the best way to periodically (yearly at most) merging the source code? Any suggestion of doing such co-operation with the minimal communiction between 2 teams?

Assumptions:
TeamA will be the one maintaining the existing code & creating new modules; TeamB in most cases will only create new modules.
The application is a N-Tier application (Client, Security, Business Logic, Access, Database) and all codes for different tier can be stored in different folder, same goes to modules.
0
Comment
Question by:howyue
  • 5
  • 3
  • 2
  • +3
15 Comments
 
LVL 45

Accepted Solution

by:
sunnycoder earned 64 total points
ID: 20337289
>what is the best way to periodically (yearly at most) merging the source code?

Yearly would be a nightmare.

Your best option is to create a single source repository.

Hold a teleconference with both the teams and decide on a directory structure. Make sure that everyone knows what code goes in what directory. Both the teams can go ahead and develop independently using the same source repository.

Whenever one checks in the code, they will have to merge with latest code. Since you would be merging in small steps all year long, it would not be too much of a pain. Ideally they should update their local copy from the repository before starting the days work and check in the days work before leaving.

To further ensure healthy development, it is highly recommended that you have daily builds. Any build breaks should be resolved asap.

This will ensure that you have a code base that is up to date and at the very least compiles all the year round.

You can look in to CVS and SVN for creating repository. Both are good and both are free.

Cheers!
sunnycoder
0
 
LVL 51

Assisted Solution

by:ahoffmann
ahoffmann earned 62 total points
ID: 20337785
I'd also recommend a network-proved  repository.
Forget about CVS 'cause the "C" which stands for concurent is the thing not working at all in CVS, I'd use Subversion, probaly Aegis or something comercial like bitkeeper.
0
 
LVL 37

Assisted Solution

by:gregoryyoung
gregoryyoung earned 62 total points
ID: 20341830
I think its imperative team A's changes get back into Team B's source base as soon as possible.

I would look at using continuous integration from team B's production branch back to Team B's development branch.


The main reasons for this are three-fold.

1) Team B doing new development may be making incorrect assumptions in their new abstractions which cause massive conflict with changes made by team A
2) Team B may have bugs in infrastructure or system libraries which really need to be pushed back to so they don't get fixed twice!
3) Team B may refactor breaking many of Team A's bug fixes (causing massive merge problems).
0
 
LVL 51

Expert Comment

by:ahoffmann
ID: 20342127
1)
2)
3)

see/use SVN ;-)
0
 
LVL 37

Expert Comment

by:gregoryyoung
ID: 20343968
umm yeah ahoffman but the goals are technology agnostic ... I am not trying to sell product XYZ I am talking about things at a process level.

btw: svn doesn't offer continuous integration unless you use a tool like Cruise Control on top of it ..

That said, the important thing is continuous integration between the right branches process-wise....



Cheers,

Greg
0
 
LVL 51

Expert Comment

by:ahoffmann
ID: 20344983
> .. continuous integration ..
agreed, but I guess that this either needs to be implemented on top of a product XYZ, or you need something commercial which forces the sync
0
 
LVL 2

Author Comment

by:howyue
ID: 20347882
Thanks for the comments.
It a bit akward to say, actually we might plan not to use any versioning control tools between team A & B. This is because both team will hav their individual versioning control tools in their own team.
0
Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

 
LVL 2

Author Comment

by:howyue
ID: 20347897
alternatively, i am thinking a very manual way to do it:
1. continous integration is a must, and will do it as frequent as possible.
2. with both team having their own versioning control tools, we might create a folder level control to the source seperating the development done by both team A & B. and make sure no team is modifying each other source.
3. whatever library or class is maintain by the team A, if teamB need to create their own subclass they will need ot maintain it in their own folder.

this is a very manual way, and is a less OO way.
0
 
LVL 45

Expert Comment

by:sunnycoder
ID: 20348148
This approach would work if you are sure that both teams would never work on the same source file.

The essence of the discussion is that you should not end up with multiple versions of the same file each containing conflicting updates. Merging such files at the end of the year (or even after one month) would be a nightmare. Since you are actively developing at different sites, conflicting changes can (and most likely will) affect functionality of the features developed by the teams. We have enough difficulty merging two different branches ... merging two trunks is unimaginable.

Even if both teams are working on different source files, it would not harm in any way to have a single source repository. You do not gain anything by having two different source repositories while advantages of having a single repository are huge.
0
 
LVL 51

Expert Comment

by:ahoffmann
ID: 20351907
> .. a very manual way ..
hmm, I guess every OS has a copy command, why not simply use that ;-)

Try: http://rsync.samba.org/
0
 
LVL 37

Expert Comment

by:gregoryyoung
ID: 20352659
> .. a very manual way ..
>hmm, I guess every OS has a copy command, why not simply use that ;-)

hmm what changed? that is a very destructive method of doing things.
0
 
LVL 51

Expert Comment

by:ahoffmann
ID: 20359056
IMHO it's destructive to ask for a "manual way" and expecting a sophisticated-out-of-the-box-never-fails-doing-everything-right-even-that-noone-can-imagine solution. Hence I recommendet to check for rsync ;-)
BTW, copy is not destructive. Move may be destructive, or copy if it overwrites the destination.
0
 
LVL 49

Assisted Solution

by:DanRollins
DanRollins earned 62 total points
ID: 20446477
If the two teams are truly independent, and if Team B's new code does not rely on existing code that could get modified by Team A... And if integrating the teams would be a huge logistical problem (differing national languages, different management structure, etc.)...

...then I too, would tend to resist imposing a rigid centralized source-control system on the two teams.  Each team already has a functional system and ... well ... if it ain't broke, don't fix it.

The issues that would tend to crop up relate to the point where "a new app" evolves into "an existing app" and gets handed from Team B to Team A.  How much work I'd put into preparing for that eventuality would depend on how often it happens and how much overlap of functionality there is.

Perhaps more of a client/vendor relationship makes sense.  For instance, if Team A is "Microsoft" and Team B is "Dan's Kitchen-Table Software, LLC" --  then we certainly do not need to have a common source control system.
0
 
LVL 1

Expert Comment

by:Computer101
ID: 20632782
Forced accept.

Computer101
EE Admin
0

Featured Post

Highfive + Dolby Voice = No More Audio Complaints!

Poor audio quality is one of the top reasons people don’t use video conferencing. Get the crispest, clearest audio powered by Dolby Voice in every meeting. Highfive and Dolby Voice deliver the best video conferencing and audio experience for every meeting and every room.

Join & Write a Comment

I worked at a US software company that used offshore contractors for ten years and offshore employees for three years. We had a positive experience and you can too.   When I interviewed people for positions in the US, I would tell them that we wor…
The Fluent Interface Design Pattern You can use the Fluent Interface (http://en.wikipedia.org/wiki/Fluent_interface) design pattern to make your PHP code easier to read and maintain.  "Fluent Interface" is an object-oriented design pattern that r…
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…
When you create an app prototype with Adobe XD, you can insert system screens -- sharing or Control Center, for example -- with just a few clicks. This video shows you how. You can take the full course on Experts Exchange at http://bit.ly/XDcourse.

746 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now