3 ms·

Why can't you just run continuous integration on all the branches?

• baq 13y ago
  have fun handling 100x build volume...
  • acdha 13y ago
    Builds are one of the easiest tasks to parallelize since they're supposed to be completely isolated by design. If you have that many active developers, you also have enough budget for extra hardware – even if you went with e.g. EC2 on-demand, you can buy a lot of capacity for what you spend on a single engineer-hour.
• mullr 13y ago
  Because that would be continuous builds on unintegrated-branches. The point of continuous integration is that everybody is reconciling their work with everybody else's all the time, thus helping you find nasty integration surprises early and while you can still do something about them.
  • calpaterson 13y ago
    I tried to explain that running tests on something is not CI, but I apparently failed :(
  • drunkenfly 13y ago
    Not if you're rebasing your branch on every change in master.
    • mullr 13y ago
      A good point. Or merging in changes from master, if you like it that way.
    • calpaterson 13y ago
      Not even then - because everyone else on the team is doing the same
• aidenn0 13y ago
  That's not CI. Example with 3 branches: Trunk Feature1 Feature2 If you nightly merge Trunk into Feature1 and nightly merge Trunk into Feature2 and test all 3 branches, you still haven't tested the integration of Feature1 and Feature2. With enough developers working on enough features the odds that at least one pair of features won't work together approaches unity. People have tried all sorts of methodology and design, &ct. to try and keep this from happening, and they haven't succeeded yet. On the other hand, if feature branches get merged into trunk as soon as they aren't completely broken, and with a way to disable them, then you will very quickly discover that the features don't play well together.