epeleg Posted March 29, 2012 Report Share Posted March 29, 2012 I am working in a multiple developer scenario, using branch per task , and was wandering how people are doing branching and merges in similar cases. Suppose you have a /main and 3 developers they are each assigned their tasks, say devA has task1 and task2, devB has task3 and task4 and devC has task5 and task6 Each developer has his own local server and there is a common server used for synchronization. Should task1 and task2 be independent branches or maybe task2 should be derived from task1? (assuming task1 is developed before task2)? (you usually don't know it there is an actual dependency between the tasks) Should each user merge his changes/branches into /main ? or should the branches just be checked in and merged on a single machine? How do you prevent "multiple heads" on /main - or do you just accept them and merge them ? Link to comment Share on other sites More sharing options...
manu Posted March 29, 2012 Report Share Posted March 29, 2012 I am working in a multiple developer scenario, using branch per task , and was wandering how people are doing branching and merges in similar cases. I hope a lot of people! Should task1 and task2 be independent branches or maybe task2 should be derived from task1? (assuming task1 is developed before task2)? (you usually don't know it there is an actual dependency between the tasks) They should be independent tasks, both starting from the same code base. In the case that the two tasks are very very very related each other you can create the second branch as a child of the first one, or create it from the same base and perform a merge from the first one. Should each user merge his changes/branches into /main ? or should the branches just be checked in and merged on a single machine? How do you prevent "multiple heads" on /main - or do you just accept them and merge them ? I'll tell you how we do it in Codice. Each time we end a task we push the branch into the central server, the Bamboo system recognizes the new branch and it runs the release test suite over it. When the task has success in the tests it's proposed to be integrated in the next release. We have a build master, a person in charge of the test system, integrate tasks, build the release and punish us with a whip is something goes bad. He creates a new branch from the main code base line called "ReleaseBLXXX", then he starts integrating all the tasks one by one running the test suite each task is integrated. If a task breaks something it's rejected from the release using the subtractive merge. When everything is Ok in the release branch it's integrated back to the base line, the merge is done automatically, it doesn't has conflicts, the build master is the only one with permissions to commit in the base line. Finally he creates and applies a new label to the release. Having a Build Master is essential if you want to be agile, you automatically get rid of subbranches and unneeded problems. Link to comment Share on other sites More sharing options...
carpediemevive Posted March 29, 2012 Report Share Posted March 29, 2012 Thanks Manu! This actually helped to clear up some questions I was having myself. Link to comment Share on other sites More sharing options...
epeleg Posted April 3, 2012 Author Report Share Posted April 3, 2012 Thanks Manu, How many developers do you have there? I don't think I can use this model right now as I don't have enough people to have a dedicated build master. but you answer did clarify some of my Q's I would still love to hear from others how they are handling this. Link to comment Share on other sites More sharing options...
psantosl Posted April 11, 2012 Report Share Posted April 11, 2012 If the team is not big enough, or if the build is automated enough (which is better), the "integrator" position can be a temporary hat one of the developers wear. Like: "hey, this week you're the integrator", and hence the guy is responsible for the merges, and everyone else enjoys vacation If merges are frequent (they must!) the time should only be spent on running the release tests, and if they're fast too (that's our bottleneck internally, 24hours of intensive automated testing paralelized to 4-5h but still too long), then the release takes nothing to do. The newest Bamboo is ready to build "per branch" (version 4 I mean) and we're working hard now to get it ready in a week or so. But, so far (check our blog) we've our own Bamboo adaptation to make it "talk" branch per task, which seems to be the industry trend. Link to comment Share on other sites More sharing options...
carpediemevive Posted April 23, 2012 Report Share Posted April 23, 2012 psantosl, how far along is the Bamboo 4 integration? Is it ready for the 4.1 release of Plastic? I have been tasked to look into continuous integration servers, and I love Atlassian's products, and want to use this as an opportunity to get some people at my place to evaluate their products. Getting Plastic integration with it would be fantastic! Link to comment Share on other sites More sharing options...
manu Posted April 24, 2012 Report Share Posted April 24, 2012 Ey carpediemevive! It will be included in the 4.1! Link to comment Share on other sites More sharing options...
carpediemevive Posted April 24, 2012 Report Share Posted April 24, 2012 Awesome!! Link to comment Share on other sites More sharing options...
manu Posted April 25, 2012 Report Share Posted April 25, 2012 4.1 is out! Link to comment Share on other sites More sharing options...
carpediemevive Posted April 25, 2012 Report Share Posted April 25, 2012 I already set the schedule to do the upgrade here for it! Very excited about it. Great work! Link to comment Share on other sites More sharing options...
chun Posted April 26, 2012 Report Share Posted April 26, 2012 Just a question for manu. After the release has been baselined, I assume your developers can see this new baseline and just create branches from this baseline for new tasks and merge from this baseline if they need to integrate the baseline for a task that they are currently working on. If not, could you please elaborate post baselining development process. Link to comment Share on other sites More sharing options...
carpediemevive Posted April 26, 2012 Report Share Posted April 26, 2012 I can't speak for Manu, but currently what I do is my release branches I treat as QA branches. These branches will be deployed anywhere I want to run some different kind of tests on (i.e. user acceptance tests or such). Then when the release is ready for production, I merge it back into main and label it there with the version number. The developers always branch their task branches off of main, and if there's any long running tasks the merge the new baseline into their branch. Link to comment Share on other sites More sharing options...
chun Posted May 1, 2012 Report Share Posted May 1, 2012 Thanks for your input carpediemevive. I thought as such, being a newbie to plastic, just needed to confirm that this was a normal practice to do. Link to comment Share on other sites More sharing options...
manu Posted May 2, 2012 Report Share Posted May 2, 2012 Hi! here in Codice we perform as carpediemevive said, IMHO we think that it's the simpler and cleaner way to build releases. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.