Get ready, RebelLabs is doing a technical report on Java Build Tools….
Historically, developers compiled and linked their code through running compiler commands through terminal. Most of these commands were pretty much the same at the time, so they decided to create special “build tools”, that could save developers some time typing commands. As you can probably guess, it’s not reasonable to use the command line if you have many source code modules and they should be compiled and linked in a particular order.
Introduction to Chef
In previous posts we discussed the benefits of having automated environment provisioning & virtualization and how to get started with Vagrant. We also mentioned how this topic relates deeply to the technoculture of DevOps, which focuses heavily on automation, reusability and iterative improvement with regards to building and releasing software.
So let’s get started with Chef, which helps you turn environment provisioning into an automated process, making it not only more reliable and error-proof, but saving loads of time and headaches.
Jenkins just keeps getting better. The world’s favorite build master becomes more mature with every year, and there more and more plugins to choose from–over 600 now and growing.
It’s been quite a while since the last post on our top 10 favorite Jenkins plugins/features, which was so popular that we even created a 50-page RebelLabs report on the same topic: Jenkins CI: The Origins of Butlers, Build Masters and Bowties and included an insightful interview with the man himself, Kohsuke Kawaguchi.
So it seems like a good time to revisit the myriad of plugins to see which new ones have been written and which new features have been introduced. Spoiler alert: Of all the plugins we covered, the Git plugin for SCM was the most frequently installed…
Jenkins. The build master in a bow tie that we’ve all grown to rely on. In this new report from RebelLabs, we’re all over Jenkins like brown on rice, or like JRebel on your classloaders.
In Jenkins CI: The Origins of Butlers, Build Masters and Bowties, we looks at all the angles in Jenkins, covering some history, our favorite features & plugins and even show you how to build Jenkins pipelines the ZeroTurnaround way–plus, we have top it all off with an exclusive interview with our friend Kohsuke Kawaguchi, the originator of Jenkins.
I was brainstorming in the shower the other day, and I thought “Eureka!” – I need to bootstrap and test my Java app on a dynamic cluster with 800 Tomcat servers right now! Then, breakfast.
Obviously, every now and then you need to build a dynamic cluster of 800 Tomcat machines and then run some tests. Oh, wait, you don’t? Well, lets say you do. Provisioning your machines on the cloud for testing is a great way to “exercise” your app and work on:
- Warming up: Bootstrap a clean slate, install the software, run your tests
- Checking your Processes: Smoke testing for deploying the app to production
- Ensuring success: Checking load handling before launching the application to real clientelle
- Leaving nothing behind: After you’ve got all green lights, shut it all down and watch it disappear
So I’ve been developing a Jenkins plugin for a whole week now, and the first few days were really tough for me – the turnaround time is just awful! At one point, I decided to make the effort to configure JRebel for this task (which is pretty easy for me, being on the JRebel team). What follows here is a quick guide for getting started developing Jenkins/Hudson plugins using JRebel. So let’s go!
The first step is to prepare your environment. Keep in mind that this is Jenkins/Hudson-specific, and you need to consult their Setting Up Environment page.
Once you have your environment setup you can create your plugin, but right now this is just an empty skeleton version.