Jenkin's is primarily configured via web ui. an evolved approach is to bundle the instructions/configurations with the project. Similar to:

• https://docs.saucelabs.com/ci-integrations/travis-ci/
• https://wiki.jenkins-ci.org/display/JENKINS/Literate+Plugin
• http://www.yegor256.com/2014/07/24/rultor-automated-merging.html

Once the build is configured, there should be an oportuntiy to supplement & override any functionality from the project embedded config file for additional features or for purposes of security.

It would be great if the configuration could bring along plugins as well.

Executing these builds should be in isolation so it doesn't bring down the server.

The current strategy of it all being configured from the UI has several negatives:

1. Encourages seperation between the developers on the build & release folks or the ops folks
2. Doesn't allow uniform and simultaneous handling & tagging of the continuous delivery config as well as the project source code i.e. I should be able to say tag the release 2.0 and the build instructions as well as the code would be versioned together.
3. makes it harder for others to understand the deployment processes

Jenkin's could be configured at a server level, project level, and then embedded as part of the project. This is similar to Maven where you can configure at the server level ($M2_HOME/conf/settings.xml) and the user level (${user.home}/.m2/settings.xml) and at the project level with pom.xml (you could several numbers of poms that inherit from each other)