Blog

The Tools & Tech Leaderboard for 2012 shows…

We’re not much for fanfare here at ZeroTurnaround, but this is our most ambitious report that we’ve ever created. This year, over 1100 Java developers shared their take on “the developer life” with us.

Want to know how much uptake Java SE 7 has seen since its release? Which IDE has grown most in user base since last year? Which application server has jumped 300% in popularity by Java developers since 2011? You’ll also get the latest numbers on Oracle WebLogic, IBM WebSphere, Eclipse, JBoss, Jenkins/Hudson, Maven, Subversion and Tomcat (alert: shameless SEO plug). It’s all in there!

In addition, we take a shot at questions like, “How do Java developers spend their work week?” and “What aspects of the coding life increase or decrease efficiency at work?” Sound good? Then sign up to get the full report!

Digging into data searching for insights is always an exciting activity. Last year’s Java EE Productivity Report 2011 was focused on tools/technologies/standards in use (exclusive selections) and turnaround time in Java (i.e. how much time is spent per hour redeploying/restarting).

This year, you will find in the full version of the Developer Productivity Report 2012 expanded coverage on technologies and tools used by Java development teams.

We also focused more on the abstract side of development. We wanted to know “What makes developers tick?” and learned a lot more about how the developer lifestyle. Our results include a lot of interesting trends and insights, so we broke them down into 4 parts:

• Part I: Developer Tools & Technologies Usage Report – coverage of Java versions, JVM languages, IDEs, Build Tools, Application Servers (containers), Web Frameworks, Application (server-side) Frameworks, JVM Standards, Continuous Integration Servers, Front End Technology, Code Quality Tools, Version Control Systems
• Part II: Developer Timesheet – How do devs spend their work week?
• Part III: Developer Efficiency – What aspects of your job make devs more/less efficient?
• Part IV: Developer Stress – What keeps devs awake at night?

Get the complete Developer Productivity Report 2012

It’s probably best to sign up to get the full Developer Productivity Report 2012, which includes the complete Developer Tools & Technologies Report, the Developer Timesheet Report, Developer Stress Report and the Developer Efficiency Report.

Job chaining in Jenkins is the process of automatically starting other job(s) after the execution of a job. This approach lets you build multi-step automation pipelines or trigger the rebuild of a project if one of its dependencies is updated. In this article, we will look at a couple of plugins for Jenkins job chaining and see how to use them to build and visualize these pipelines.

• Out of the Box Solution
• Build Pipeline Plugin
• Parameterized Trigger Plugin
• Downstream Buildview Plugin
• Conlusions

Out of the box solution – Build Other Projects

Jenkins has a built-in feature to build other projects. It is in the Post-build Actions section. You can specify the projects that you want to build after this project is built (you can trigger more than one). So whenever project A is built you will trigger the building of project B. You can also specify the conditions when the other jobs are built. Most often you are interested in continuing with the pipeline only if the job is successful but your mileage might vary.

One thing to remember here is that this feature has two configuration location. You can configure project A and specify a post action as in the previous screenshot. Another option is to configure this from project B and say “build this project B only after project A is built”. You don’t have to fill out both, just change one and the other is updated. See the next screenshot for the second option.

Build Pipeline Plugin

Build Pipeline Plugin is one interesting plugin. The main features of this plugin is to provide visualization of the pipeline and also to provide manual trigger for continuous delivery purposes. The configuration is a separate Post Build action where you can configure which projects should be built after project A. By default the triggering is actually done manually by the end user! If you want certain steps of the pipeline to be automatic then you have to use the built-in job chaining (see the Out of the Box Solution for more details).

The pipeline plugin offers a very good visualization of the pipeline. By configuring a new Jenkins view and choosing which job is the first job in the pipeline you can get a visualization of the whole pipeline. In the screenshot, be sure to note that one of those steps is manual and the result are automatic. The manual one can be triggered from the very same view.

Parameterized Trigger Plugin

The Parameterized Trigger Plugin is another triggering plugin but with a twist: this plugin lets you configure more aspects of the triggering logic. It covers the basic Out of the Box Solution features and adds many more. The most important one is the option to trigger the next build with parameters. For example, by defining SOURCE_BUILD_NUMBER=${BUILD_NUMBER} you are able to use the variable $SOURCE_BUILD_NUMBER in project B. This way you can, for example, use the artifact built in the previous job to be fetched from your central artifact repository using the ${BUILD_NUMBER}.

Downstream Buildview Plugin

The Downstream Buildview Plugin plugin that does not do job chaining itself, but provides a means to visualize the pipeline. Similar to the Build Pipeline View but more dynamic. You can click on any item in the build history and have its pipeline visualized.

Conclusions

The main feature that makes Jenkins so good is that there is always an app plugin for what you need. Of course, the same fact also highlights its biggest weakness. It is rather difficult to choose the correct plugin and very often you need a couple of plugins to achieve your goal. The same is true for job chaining and visualization.

The job chaining features that we covered in this post all provide the minimum functionality – triggering other jobs. The Parameterized Trigger plugin is the most feature-rich, but lacks the manual triggering. The Build Pipeline only offers manual triggering and you need to figure out automatic triggering yourself (using the built-in feature for example).

From the visualization side, the Build Pipeline plugin is definitely the best looking. At the same time, the plugin does not support passing parameters (the latest alpha build is a bit better) and once the pipeline gets long it gets a bit ugly. We do like the part of defining a separate view and then always being on top of your pipeline. The Downstream Build View plugin gives you great flexibility and insight to job chaining, but does not enforce any kind of process.

So, there are the Jenkins plugins that we use at ZeroTurnaround for job chaining and visualization. DO you use the same tools? If not, can you recommend any others? Which are your favorites? Please leave comments below!

This week we released a new minor version of JRebel. You can download the latest version of JRebel right now.

The new version includes a number of bugfixes and improvements for GWT, Tiles, Spring, Liferay, JBoss, etc. See the changelog for the full list of additions.

There’s one very specific fix that concerns Spring users: for the <include> directives in Spring XML configuration files, if the included resources are specified using wildcards (*), given there’s multiple resources with the same name, the things didn’t work quite well.

The current release now includes a small fix, which is actually disabled by default, that tries to fix the aforementioned shortcoming. The feature is enabled using -Drebel.spring.classpath_classloader_delegate=true VM argument.

We’re still working on JBoss 7 CDI integration making it more stable with every release. Hopefully we can cover all the use cases, and we’re looking for the users’ feedback!

Download the latest version of JRebel today!

Last week was a great week for ZeroTurnaround. On Monday we grew by 10% head count wise and I plotted the trend. It was humongous. My calculations showed that we will reach 600 billion people by the end of the year. This introduced a lot of questions and couple of interesting threads. Also it meant that our first intern ever hired had a lot more on his plate than first expected. I’ve compiled one of the public threads just for you guys. It tells you how and why we have a document Will ZeroTurnaround reach Gravitational Singularity and also to state that we actually don’t pack people together 100% flesh to flesh.

ZeroTurnaround and Red Hat’s JBoss teams have been spending a lot of time working to make Java faster, more efficient and more community-based. We already support the JBoss Forge team with free JRebel OSS licenses, and now we see that the JBoss Arquillian team has started to see the real value in cutting out redeploys in development using JRebel.

JBoss Arquillian is an awesome tool for integration testing of enterprise Java applications brought by JBoss folks to the community. It enables real in-container testing with no mocks, and writing the tests is made very simple, just like if you would write ordinary unit tests.

Even though Arquillian improved integration testing experience a lot, it still deploys the test suite to a container, and doing that repeatedly leads to the problem that JRebel fights against, avoiding restarts and redeploys. With the brand new JRebel extension for Arquillian the tests are deployed only at the first execution, and for the repetitive runs JRebel kicks in and updates the test and application code in the running container.

Arquillian 1.0.0. final was released just recently and some splendid news were announced last week: a special JRebel extension was added to Arquillian project.

Source code is available at Github: https://github.com/arquillian/arquillian-extension-jrebel
And you can track the progress in the dedicated JIRA: https://issues.jboss.org/browse/ARQ/component/12315771

P.S. Arquillian guys: if you need any more free JRebel licenses, write to oliver@zeroturnaround.com

We’ve been getting a lot of sweet coverage lately. Maybe it’s our most recent award for LiveRebel at EclipseCon 2012, or the fact that we’ve hit up a pretty hardcore conference circuit already in 2012. Either way, it’s always good to get love from Basement Coders, InfoQ and JAX :-)

Basement Coders

The guys at Basement Coders are some of the most fun people to hang with in the Java industry (and they even gave this simple marketing droid a shout out on their website). They rocked out a funny, fierce podcast with Jevgeni that stretched for nearly an hour, and garnered no small amount of energetic feedback in the comments area. The main topic, outside of ZeroTurnaround’s product news, was OSGi, or, as Craig put it, “OSG-why?”. Not a bad question!

Look forward to seeing you guys at JavaOne 2012 :-)

Check out Basement Coder’s Episode 52 – JRebel, LiveRebel and OSGi with Jevgeni Kabanov

InfoQ

InfoQ’s Charles Humble and fearless leader Jevgeni Kabanov had a nice interview during QCon London about JRebel, LiveRebel and some of the challenges faces Devs and Ops teams these days. Click on the picture below to get to InfoQ’s interview with ZeroTurnaround CEO Jevgeni Kabanov

JAX Conference – Mainz, Germany

Toomas, our Director of Engineering and Founder, once told me he couldn’t handle German conferences any more because the 13-hour exhibitor and conference schedule was a little too rough. So what if both Toomas and Anton (our JRebel Product Lead), both gave talks on the same day at 830 AM! In any case, we met some good folks at JAX this year, and there was even an opportunity to lightly embarrass myself with an impromptu interview onsite – hopefully I was coherent enough to be understandable :-)

The first thing you notice about Alex Laats is how he looks like he could take on Chuck Norris. But go past the tough facade, fashioned over the last 8 years building up and selling IT firms that have specialities in military technology, and you will find a calm, down-to-earth guy.

From April 15th, ZeroTurnaround’s Boston offices (our HQ is *still* in Tartu, Estonia) is where you will find Alex much of the time during the day, taking the position of ZeroTurnaround’s President and Chief Operating Officer.

With Estonian roots and a history of turning small, niche IT startups into powerhouse suppliers later bought out by major firms like Raytheon (Laats was Division President at BBN Technologies since 2004, which Raytheon bought for $350 million USD in 2009), Alex is looking to hit the ground running at ZeroTurnaround.

“[ZeroTurnaround's] products are delivering real value for customers and the product vision is fantastic,” said Alex in an interview with the Boston Business Journal.

As COO and President, Alex will be challenging himself with the responsibilities of ZeroTurnaround’s day-to-day operations, finances, HR, analytics and go-to-market strategies.

“Alex has a great deal of experience taking products to market, forging strategic alliances and building an analytics machine across sales, marketing, finance and operations. I believe that his skills and experience will complement mine greatly, allowing me to focus more on our roadmap, products, customers and outreach. It is our hope to forge a partnership that will help this company grow while preserving our mission,” commented ZeroTurnaround’s CEO, Jevgeni Kabanov.

Welcome to the team, Alex – and may the force be with you…

This is Part 1 of a three-part series designed to extrapolate on the concept of Continuous Delivery in the context of DevOps, the process flow and tools involved, and a suggestion for implementing these processes.

What’s all this DevOps stuff?

Over the last year or two, organizations with strong development teams have undergone something of a revolution. It really began in 2001 with the Agile Manifesto signalling the end of the waterfall methodology in software development, in favor of Agile tools and processes. These tools (Scrums, sprints, etc) have set the stage for what is turning out to be the ‘third renaissance’ in software development. “DevOps” – the merging of Development and Operations – viewing the entire delivery cycle of software as a single process, rather than the walled silos of old – is the stage for this new approach to application deployment: Continuous Delivery. (Read up for more understanding of Continuous Delivery vs. Continuous Deployment)

A New Approach to Application Deployment: Continuous Delivery

Enough with the buzzwords and lofty history chat. Lets get into the meat and potatoes.

Continuous Delivery is an extension of the DevOps approach to managing the software development, build, testing, and deployment process. The first phase of Continuous Delivery, Continuous Integration, has now become commonplace in many organizations. Continuous Integration allows for hot-builds of applications immediately after check-in and compilation of existing code. If the code compiles cleanly and gets the green light, it is automatically deployed onto a Continuous Integration server and is available for immediate testing; however, we have seen that most firms are still incapable of automating their deployment processes.

This has been a huge boon to the software industry. Code that is actively being developed may be viewed and tested by people not intimately involved in the development process, without any user intervention. The application appears on the CI servers within minutes of a check-in by the developer (assuming nothing broke), giving visibility into a project outside the local coterie of coders.

How does Continuous Integration extend into Continuous Delivery?

Taking this concept further, Continuous Delivery takes CI and extends it beyond just CI servers, allowing for deployment of code all the way up the service chain. Not only can code be hot deployed to CI servers, but the same code should be deployable to all test environments (QA, Testing, and Staging), and, with basic checks in place, right to Production. With a properly built environment, the same code that comes out of the CI server can be deployed all the way up the chain, without any changes to the built package.

So why do this?

The goal of Continuous Delivery is not just making updates to the environments automated. That part is easy, and has been implemented many times before using automated deployment tools like Puppet and Chef. The difference here is that Continuous Delivery takes a much more holistic approach to the problem, and looks at it in the following way:

All environments should be as similar as possible; the same packaged code should be able to be deployed on any server, in any environment, without requiring customization or manual intervention.

I’ve heard that before – isn’t it too hard?

Not really!

Java applications in particular have this capability intrinsically. Applications are bundled into an easy to deploy package (JAR, WAR, EAR, etc), and the containers are by default set to accept this file as the entire application, and manage it appropriately. Generally the issues are not with the deployment methodology, but with the application itself. We’ll go into some of the pitfalls of implementing a Continuous Delivery strategy in Part 2 of this series.

There’s a great phrase you find in a lot of Continuous Deployment resources:

“If it’s hard to do, do it more often.”

Think about this for a few minutes. If there’s a rough spot in the deployment chain, does it make sense to avoid it and leave it there, like a speedbump on the autobahn? No! Focus in on it, keep going over it and smooth it out until it’s no longer an obstacle!

What benefits does Continuous Delivery bring?

The primary goal in any Continuous Delivery solution is to streamline the delivery pipeline from the developers desktops all the way out to production. With automation, proper testing, and clean configurations, the average Continuous Delivery implementation can speed up the delivery process by two orders of magnitude. Whereas before, the delivery lifecycle might be 6 months, (180+ days), a stable and well-established system can allow for software updates to drop down to a few weeks, or a few days. Removing the stress and worry about deployment into production allows for faster updates, more often, with less downtime and happier end users.

What kind of impact can I expect on our organization?

Probably the most concrete example of a successful implementation is by looking at the ‘turnaround’ time from when a bug or feature is requested on the production side of the environment, and when that bug or feature is implemented.

In a standard (ie ‘waterfall’) environment, the bug would be noted in the production environment. It would be slated for the next release of the product, and resources would be assigned to fix it. Once that cycle was complete, the product would ‘waterfall’ through QA, Testing, and Deployment, and the fix would go live with the next release.

In many organizations, this process could take months. With a fully implemented Continuous Delivery process, this could take days, if not hours.

That’s the win.

Snap! Ok, how do I get there?

Continuous Delivery requires some specialized tools and thought about how your products are packaged and distributed. In Part 2 of this series, we’ll take a look at some of the tools that are available, and look at how to start preparing your existing environment to better adopt Continuous Delivery concepts.

“GeekOut is the coolest and most laid-back event in the Baltics for me so far. It was One day, One track, One crowd in 2011. Highly interested coders, great medieval setting in Tallinn and the great care of the ZeroTurnaround conference crew make this one of the best kept conference secrets in Europe.”

- Peter Neubauer, Neoj4, speaker from the first ever Java Developers Conference in Estonia.

What’s happening at GeekOut 2012?

You better get ready for a tech-vacation in the capital of e-Country Tallinn, where startups grow on the trees and developers are productive (thanks to JRebel). Ed Burns, Kirk Pepperdine, Jaroslav Tulach, Matthew McCullough and more speakers are there for your benefit, helping you get new angles and views. Not to mention having some time to discuss that with your team-mates, other devs around Europe.

We had developers from over 30 Estonian companies+some Finnish. We had Peter Neubauer, John Davies, Martijn Verburg, Joonas Lehtinen and Alex Snaps as the speakers and over 130 developers attending. I bet they all remember a full day tech-talk topped with beer and pizza? Having a successful conference and receiving feedback that the event should be larger this time, we set the date for June 14th – 15th in 2012 and can list over 10 Java experts from around the World to come to little e-Estonia. It is an ambitious plan, that you can be part of in fulfilling by attending the conference.

Six reasons to come if you are a developer:

• 12 talks to attend a choose from during two days;
• Highly technical talks to learn best practices;
• Get inspiration at evening party&networking by meeting speakers, other developers over a beer and discuss how you can improve your work;
• Get time off to discuss work in light of new ideas with your own team;
• Cloudbees, Vaadin, Odnoklassniki.ru and more to come to show off their tools and projects;
• You can make it into a small vacation, exploring the beautiful Tallinn over the weekend.

Four reasons you can tell your Team Lead or HR Specialist to send you to GeekOut:

• The conference will increase developers motivation and productivity;
• Developers can learn best practices and get ideas;
• A chance for your team to take time and talk to other team members, field experts and – colleagues getting ideas how they can improve their work, what they are doing wrong and what else could be done to add value;
• Estonia is a close by and reasonably priced country so you can send more developers to get trained then with a regular conference.

Don’t miss out the GeekOut 2012!

It would not be hard to imagine, at this point, that President Toomas Ilves of Estonia has a soft spot in his heart for ZeroTurnaround.

For the second time in 6 months, we’ve been privileged to receive the Estonian President in ZeroTurnaround offices. This time, he visited our Boston office. Back in November, shortly before we were recognized as the #1 company in Estonia to watch in 2012, President Ilves visited ZeroTurnaround’s headquarters in Tartu, Estonia.

Find President Ilves...(hint: look for the bowtie)

President Ilves is keenly interested in a hands-on approach towards the proliferation of Estonian-headquartered companies around the world, some of which are located in Boston and other cities in the USA. And for good reason: he is a key driver of e-Estonia, the term coined to describe Estonia’s “incredible success story that grew out of a partnership between a forward-thinking government, a pro-active ICT sector and a switched-on, tech-savvy population.”

President Toomas Ilves and ZeroTurnaround's newly-appointed President and COO Alex Laats

From the ZeroTurnaround team, thanks for your support and we look forward to your next visit, Mr. President!

Older Entries »