Continuous integration doesn't mean all development happens in master. A policy that works well for me is that anything that will require more than 2 minor commits to accomplish should happen in a feature branch. If tests pass in the branch (and you probably want to insert code review/sign-off at this stage as well), merge to master. If tests pass in master, deploy.
From what I can tell, this just makes it easy to run tests in branches. My team uses something similar that kicks off a build whenever someone comments "build it" in a GitHub pull request, and posts the results to the pull request discussion.
It sounds like we agree that long-lived branches are not continuous integration at least. We probably differ in that I think short-lived branches and pull requests are more overhead than most teams require. Keep in mind that CI does expect daily check-ins to master. That's how short those branches can live to satisfy that requirement. Anything else is not CI... which is not the end of the world either, but I don't see the point of using a CI server at all anymore. Just build/test your stuff locally.
So what benefits are you saying are lost/given up by this model that another model preserves?
Also, feature branch development is just how we're using it. The code monitors git for any new branches and automatically clones jobs for new branches. This would support a more traditional master branch with release branches created periodically. Those release branches would automatically get Jenkins jobs created for them instead of someone manually having to do it.
I'm saying a CI server is unnecessary for these branches that aren't ready to integrate with master. These are short-lived branches with 1 or 2 contributors, right? Just run the build/tests locally. There's no advantage to this overhead with branches that won't last longer than a day.
russell_h|13 years ago
From what I can tell, this just makes it easy to run tests in branches. My team uses something similar that kicks off a build whenever someone comments "build it" in a GitHub pull request, and posts the results to the pull request discussion.
Ramone|13 years ago
tednaleid|13 years ago
Also, feature branch development is just how we're using it. The code monitors git for any new branches and automatically clones jobs for new branches. This would support a more traditional master branch with release branches created periodically. Those release branches would automatically get Jenkins jobs created for them instead of someone manually having to do it.
Ramone|13 years ago