HgParallelTeamIntegration
Parallelized Team Integration (PROPOSAL)
Not in use, current proposal is HgParallelProjectIntegration.
This is enhancement of MercurialBuildInfrastructurePlan and alternative to HgTeamIntegration. A newer proposal not yet adopted is in HgPerDeveloperBranch.
A prototype is running with core-main and the continuous build setup.
Contents |
Best Practices for Developers
HgParallelTeamIntegrationBestPractices
Description
Each team should have their own integration repository. There should be concurrent integration of team repositories to main.
Algorithm
two jobs running in parallel for each team repository. Each team should have its own instance. All the instances will be the same.
- the network issues catching is not described, but need to be addressed - if any of commands fails the mail should be sent to the team.
- build with tests action - build the full IDE with well defined suite of stable tests, it is up to QE and development to define them.
golden => team repository push job
Triggered by change in main-golden
cd /golden-mirror hg pull http://hg.netbeans.org/main-golden rm -rf /team-integration hg clone /golden-mirror /team-integration cd /team-integration hg pull -u http://hg.netbeans.org/team-main HGMERGE=merge hg merge hg megre (*) hg ci -m "Automated merge" hg push http://hg.netbeans.org/team-main (**)
(*) If merge failed send an email to team about conflict between team repo and golden-repo. Team needs to handle this situation manually in one of their working workspaces.
(**) If push fails repeat pull, merge, commit and push round. The number of repeats needs to be specified
Team repository => main push and build
Triggered by change in team-repository
cd /team-repo hg pull http://hg.netbeans.org/team-main rm -rf /team-build hg clone /team-repo /team-build cd /team-build hg pull -u http://hg.netbeans.org/main HGMERGE=merge hg merge hg megre (*) hg ci -m "Automated merge" build with tests (**) hg pull -u http://hg.netbeans.org/main hg push http://hg.netbeans.org/main
(*) If merge failed send email to team about conflict between team repo and main. Team needs to handle this situation manually in one of their working workspace
(**) if build or tests fail team is notified about unsuccessful integration with main repository. Team needs to handle this situation manually in one of their working workspace
main-golden repository is being populated by production build.
- The advantage of the algorithm is that its speed doesn't depend on number of teams and team repositories.
- The turnaround only depends on speed of machine where the described jobs are running.
- In case of emergency we may do pushes directly to main.
- It is easy to prototype.
- The biggest disadvantage is that there is no assurance that main repository doesn't get broken, because if there is conflicting change in main during the repositories build then the push to main can happen and main could be put to inconsistent state. However there is still a lot lower probability for this scenario to happen than for everybody pushes to main scenario.
Solving conflicts
In case main becomes unbuildable there are two options:
- the teams who did last push to main will fix it and others will wait until it gets propagated to the main
- some well known authority steps in and rollback the offending commit directly in main (only few people would be allowed to do such a thing)
In any case broken main doesn't prevent teams from work in their private team repositories. They could have their own CB setup too.
There is also option to enhance the second job, so it would look like:
cd /team-repo hg pull -u http://hg.netbeans.org/team-main clean build with test (*) rm -rf /team-build hg clone /team-repo /team-build cd /team-build hg pull -u http://hg.netbeans.org/main HGMERGE=merge hg merge hg megre (**) hg ci -m "Automated merge" build with tests (***) hg pull -u http://hg.netbeans.org/main hg push http://hg.netbeans.org/main
(*) if build fails team is notified about bad situation in their team repository.
(**) If merge failed send email to team about conflict between team repo and main. Team needs to handle this situation manually in one of their working workspace
(***) if build or tests fail team is notified about unsuccessful integration with main repository. Team needs to handle this situation manually in one of their working workspace
