Introduction to Jenkins and ElasticBox
ElasticBox has recently released a Jenkins plugin which makes it possible to configure a continuous integration or continuous deployment scenario without writing any code or scripts! How have we done this you ask? Simple, it was magic. In all seriousness, magic is the end result if you integrate ElasticBox and Jenkins with the source control software of choice.
For those who rely on Jenkins for daily work, performing integration builds, orchestrating complex, large scale scenarios for testing or managing continuous delivery of applications with many configurations across multiple environments, is not uncommon. These types of scenarios require a lot of time setting up slaves and performing manual steps to configure the provisioning of cloud providers. Keeping consistency and across the environments becomes exponentially complex when you factor multiple clouds or hybrid cloud environments into the picture.
You can reduce the amount of manual configuration and scripting, while abstracting the provisioning of infrastructure, by using ElasticBox with the ElasticBox Jenkins Plugin. This means that you can use ElasticBox to solve complex continuous integration or deployment use cases in the quickest, most consistent and reliable way possible.
How Does It Work:
Here at ElasticBox we trigger tests, builds, and deployments on pull requests and merges, which is a very common use case. These actions start workflows that result in Jenkins triggering tests, builds and the deploying of instances. For more information on our internal continuous deployment scenario, take a look at this slideshare deck we presented earlier this year.
The first thing to understand is that we manage Jenkins as an instance that we deploy into our private datacenter through ElasticBox. We have a single Box that installs Jenkins Server on the provider of your choice. This makes it convenient to scale when multiple builds are slowing things down or to simply redeploy if something breaks all together.
The second piece of the puzzle are the required plugins, like the recently releasedElasticBox Jenkins Plugin, which, along with the Github Jenkins Plugin, makes it entirely possible to set up a continuous integration or deployment server without writing any code.
Setting Up Jenkins and ElasticBox:
First you have to set up ElasticBox as a cloud in the configuration page of Jenkins. You simply enter the ElasticBox url (http://elasticbox.com), a maximum number of instances, retention time, in minutes, and your ElasticBox username and password. Once all this information is entered correctly, you can go ahead and then test the connection.
ElasticBox Jenkins Example:
In this basic example, we’ll show you how we test changes to our website. When a branch is submitted as a pull request, we deploy a new staging instance of our Website Box. We validate the changes on an instance that is a replica of our production environment before merging the pull request into our master branch. When the code is merged, we then trigger a Jenkins job that reinstalls our production instances with the latest code changes (not shown in this demo). Now, our workflow for website changes is almost fully automated, minus the pull request and merge!
1) The first step is to create a new Jenkins item where we select “Build a free-style software project”
2) Once we’ve created a new item, we add the Github project URL and check the ‘this build is parameterized’ box. While this step isn’t required, it allows you to trigger a build manually and execute code from a specific branch.
3) In the source code management section, we specify the source code management tool, the ‘Repository URL’, provide credentials in the form of Username / Password, and for the Branch Specifier, use ‘${sha1}’ which represents the commit url of the branch submitted in the pull request. The Jenkins Git plugin is extremely complex and we highly recommend reading the Wiki on the plugin.
In the Build Triggers section, you’ll want to select “Github Pull Request Builder” Which is what will be triggering the Jenkins build and instance deployment in ElasticBox.
4) The final step is configuring the Build steps. With the ElasticBox plugin, you’ll have access to all your workspaces, boxes and deployment profiles. For more information on each of these features, please check out the links to our documentation. Specify the Workspace, the Box and the Deployment profile you would like to use. In our case, we specify our Production Workspace, our Website Box and our Staging Deployment Profile.
Conclusion:
Once all these configurations are set, you can test changes on new staging instances just by submitting pull requests. Even though this is a basic example, by continuous integration standards, you can see how the ElasticBox Jenkins plugin can seriously reduce the amount of configurations required to setup a continuous integration server.
With ElasticBox abstracting the infrastructure provisioning and allowing you to reuse existing application or infrastructure components, it’s much easier to scale the process in a repeatable and dependable way. We’ll be following up with blog posts that provide more technical examples on how to use Jenkins and ElasticBox for integrated builds, testing and continuous delivery models.
