Running Jenkins in a hybrid mode
One of the upcoming patterns of usage with Jenkins is where an on-premise Jenkins controller has a mix of agents on-premise and in the cloud. The Amazon EC2 plugin is a good example of it. However the issue with the plugin is that you end up paying for an hour regardless of the usage. The CloudBees Cloud Connector plugin lets users use CloudBees DEV@cloud agents seamlessly from their Jenkins controllers and since CloudBees bills by the minute, you pay for what you use.
Too many jobs, not enough agents...
If you're already a user of the CloudBees Free plugins, then you're probably already familiar with our "Wasted Minutes" plugin:
It's a plugin that simply tracks how much time a job spends waiting in a queue for an available executor. If your jobs are consistently racking up a lot of queue time, then that's a sign that your controller needs a few more executors.
However, many organizations simply don't have enough resources to allocate additional build machines. Instead of suffering an inefficient controller, these organizations will now have the option to offload certain jobs to a CloudBees-managed agent pool.
How Jenkins cloud bursting works
CloudBees is offering an open-source Jenkins plugin that allows both open-source Jenkins and Jenkins Enterprise installations to "rent" agents on-demand from DEV@cloud . This agent pool is comprised of Linux and OSX/iOS agents.
While some organizations can use this plugin to simply offload some of their build and test jobs to our Linux agents, others can automate their mobile development with our virtualized iOS/OSX cloud. Our cloud agents use virtualized containers (LXC) to multi-tenant applications on our infrastructure:
For a tutorial on how to use agents in the cloud with on-premise Jenkins, check out the guide in the CloudBees Developer Wiki.