Recently I tried travis CI out. It doesn't have all the bells and whistles jenkins does, but a huge value-add is that the configuration associated with the build job for a particular repository is read from the repository itself. In order to configure a travis job, one checks in a file specific to travis to one's repository, instructing travis how the code should be built.

This has some huge benefits. At our company, we have many job configurations, some for the same code base but different branches, etc., and we have no way of checking this configuration into a repository in an organized way. This means it is more difficult to find bugs in our configuration, revert changes, tell who made a configuration change, etc. All of these problems are mitigated when the configuration for a job is checked in to a code repository.

More benefits are added to this when it is realized that the configuration for a job is lock-stepped with the commit in the code. This means that when the code branches, so does its corresponding job configuration. When we want to create a release from a branch, we simply change the job config and commit it. Then we change it back in future commits and tag the release commit for historic reasons.

It would be a huge value-add and a reason for our company not to switch from jenkins if there was a way to check in important parts of normal jenkins job configuration, such as what should be run, who should be emailed, etc., to the repository which jenkins is actually building, and only worry about configuring jenkins with what repository to build, etc.