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.
There are lots of advantages for us.
What if the full build and test suite takes longer to run than you want to occupy your computer?
Unit tests are quick, but the full set of unit/integration/functional tests? Plus ensuring that artifacts like .war files can be successfully created, and that it runs fine on the target system rather than just on your dev laptop (which for most devs is not the same platform as they deploy to).
What if you want to show off your work-in-progress by having a job auto-deploy it to a test server so that your customers or QA can play with it before you're ready to merge to master? Sometimes a day is too long to wait to show something off. Commit and publish as a branch and you can keep working while someone else looks at it.
We have another dev code review every pull request to master to ensure code quality as well as spreading knowledge of what's happening across the team. The overhead is surprisingly low. Branches literally take about 15 seconds to make, and pull requests are no more than a minute or two unless you really go into testing instructions.
Well every team is different, so I shouldn't try to say I know the right thing for your team. What you're talking about though is farming out your branch builds/tests/deploys to jenkins, which has nothing to do with CI, but still sounds like your team finds it useful. Carry on if that's the case. While I wouldn't personally solve the problem that way, I'm wrong to suggest that jenkins should only be used for CI.
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.