It's all about the answers!

Ask a question

A stream for each developer?


Eric B (1112) | asked Nov 13 '19, 2:10 p.m.

Hello,

Is there any technical/logical justification for creating a stream for each developer? This is a large project made up of about 8 teams, with 6 to 8 developers on each team. Currently, there is only a stream for each team, and then a main release stream. For uncontrollable reasons, the code cannot be componentized so on a daily basis, teams are constantly stepping over each other with code changes. Team 1 will make a change on class ABC and team 2 will make another change on the same class and this happens across teams and classes all day long. Resulting in a nightmare for code merging and accepting changes from release back down to each team. The school of thought is that each developer would have their own stream so, they would resolved defects locally before pushing changes to the main release stream.

Would a stream for each developer compound problems, or increase issues (e.g. gap conflicts), or would this be an amazing model for a large project?


Comments
Eric B commented Feb 27 '20, 8:54 a.m.

Need to revisit this question...

I'm looking for the technical reasons as to why a personal stream should NOT be used and only personal workspaces should be used. For example-

1) Using personal streams in a project will ____________.


Geoffrey Clemm commented Feb 27 '20, 10:05 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Not allow the user to use any of the IDE's (such as Eclipse or Visual studio), since they require the user to have a repository workspace (you cannot load a personal stream into a sandbox .. you can only load a repository workspace).   Also, if you cannot resolve any conflicts with personal streams, since conflicts can only be resolved in a repository workspace. 

2 answers



permanent link
Geoffrey Clemm (30.1k33035) | answered Nov 13 '19, 6:59 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Each developer should not have their own stream, but should have their own repository workspace. 

If you are having too many broken continuous builds, as Davyd indicates, tell developers to do a "private build" in their repository workspace, to confirm they have't broken the build, before delivering.
Or at least, tell the developers who are breaking the continuous build to do so.


Comments
Eric B commented Nov 14 '19, 7:37 a.m.

Thanks, I completely agree and wish it were in my power to say it so.


Geoffrey Clemm commented Nov 14 '19, 9:05 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

If nobody is willing to act differently, it is unlikely that the problem will go away on its own :-). 


permanent link
Davyd Norris (2.2k217) | answered Nov 13 '19, 5:41 p.m.
edited Nov 13 '19, 8:32 p.m.
Developers technically already have their own 'stream' in the form of the repository workspace. And yes, they should be resolving defects before delivering to the team stream.

To me it sounds like you are adding complexity to try and fix an integration problem - my suggestion is to go back and fix the componentization issues ASAP. Even if it's a hard problem, it will be worth it in the end and it's only going to get worse the longer you leave it.

Your SCM setup sounds almost textbook - do not change that. Your code structure sounds like where you should focus big time, and maybe a little developer process in the mix as well. Best of luck


Comments
Eric B commented Nov 14 '19, 7:35 a.m.

Thank you for the answer. I truly wish it were possible to fix the code but unfortunately it's not. It's technically, logistically and cost prohibitive. Yes, agreed that long term costs would outweigh but the domain knowledge is missing which makes it logistically impossible so the cost is justified, with understanding that it will take years of maintenance in order to compartmentalize business logic.

I'm hoping the correct decision is made by leadership and the proper phased version control model is chosen.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.