In my recent talk on introducing Disco - the DI container with the damn coolest name(tm) - I talk about why I believe that using XML or any other non-code configuration (YAML, JSON, ...) is not a good idea. This stirred some twitter discussion recently which led to this blog post.
A few weeks ago I gave a presentation at the Jenkins User Conference London 2015 about how we have set-up and use Jenkins to power our builds. One idea I mentioned in the talk and I`d like to share now is how we bind our jobs to specific buildnodes. Given the fact that we are doing lots of different projects for different clients we have quite a few buildnodes to cover every use case we need. When we started using Jenkins about 4 years ago we bound every job to a set of specific buildnodes (e.g. buildnode01 || buildnode02). When our setup grew, it was not easy to keep up-to-date to figure out which buildnodes offer which capabilities. In the end this lead to jobs failing every now and then because Jenkins picks a buildnode from the list which does have all the required tools installed, this behaviour I call the "Jenkins law".
Recently we developed a mobile application based on Sencha Touch and Cordova. The application was communicating with a REST backend. Since I did not want to change the URL to the REST backend manually when deploying the app in the testing or production environment, I was looking for a way to use multiple configuration files based on the active environment.