The latest expert opinions, articles, and guides for the Java professional.

Beyond the commit: 6 developer tools & technologies you should know

Screenshot 2014-06-26 17.43.45

We’re developers, so we love to code right? We’re happy when our code is running…but wait a minute: how are we supposed to ship our code?

I’m pretty sure your end-users won’t agree to start your project inside your favorite IDE, so this means assembling all the bricks to make your product as professional as we can, including coding, managing resources and building the app.

I was thinking about how developers often aren’t aware of any tools that extend the reach of their development environment. Basically, we like to stick with the good old Eclipse-Maven-Tomcat-Hibernate-Spring-JUnit combo, occasionally sprinkling in some FindBugs or something. It got me thinking that maybe a lot of you out there aren’t aware that as Java developers, we actually have the most robust tooling ecosystem of any programming language. So if you’d like to know more about what happens beyond the commit, and why as the creators of the code you should care more about what it’s doing in production, then I propose to share with you the development and build environment I like to use and tell you why I like it. We’ll cover:

  • Version Control Systems (VCS) – Git
  • Source code hosting – BitBucket
  • Build automation – Gradle
  • Build platform – Shippable
  • Deployment platform – LiveRebel
  • Publishing platform – Bintray

N.B. I bet you think I’m going to write about IDEs, right? Well, I won’t because it’s an everlasting war between users. My own 2 cents are this: some like Eclipse (not sure why), and others play with NetBeans because they haven’t tried IntelliJ IDEA yet… ;)

Version Control Systems (VCS) – Git

Java tools and technologies landscape 2014 VCS technologies used

Nowadays it’s absolutely mandatory to use a version control system. Imagine that, in the middle of fixing a bug, you get switched over by management to something more urgent that needs to be handled that very second. This means stopping and switching code bases, with the understanding that you need to go back to it all later. We don’t want to screw this all up and erase code (like I’ve done before), so this is why we have a version control system.

Screenshot 2014-06-26 17.45.31

Personally, I like Git over Subversion (SVN), and it seems I’m not alone: in the recent Java Tools and Technologies Landscape for 2014, we saw for the first time Git (69%) overtake Subversion (57%) in overall usage. That said, most respondents use different technologies on different projects.

Git is very powerful and has a big advantage compared to SVN: the branching concept. So if you’re doing your fix on a branch and your boss comes around, you can just commit your changes locally to that branch, switch to the branch your boss wants you to switch to, do the modifications, commit and push to the main repository and then go back to your fix. Nothing is lost, and you get your workspace exactly in the state you left it in. Awesome!

Moreover it’s almost impossible to lose data from Git: it manages any conflicts between different file versions. You decide what changes to apply, without any black magic changing your modifications for no reason. In addition, Git is simple to start with but powerful enough in its complexity to lure advanced users. Indeed it is very easy to use with basic features, but if you want to go deeper into the subject you can. For example, rewriting your whole Git history to change the email address of the committer and so on. There is one tool I really like to manage my Git repositories (outside of plain old terminal), and that’s SourceTree, a free product by Atlassian that works on both Microsoft Windows and Mac OS X.

So go out there and git init your project!

Source code hosting – Bitbucket

Once you have your code sources all committed and ready to go, you’re going to need some source code hosting. Why? Perhaps you’ve already encountered a situation where your laptop with all your source code on it suddenly crashes. And the only thing you figured out to do to get your precious back is to use another laptop you connect to your old bumblebee with a firewire cable and retrieve data … (yes it happened to me, twice). So why not host your code?

Screenshot 2014-06-26 17.45.50

For many people using Git, the logical choice for source code hosting is GitHub, which I think is a great tool that has a lot of hooks available for integrating it with different services like JIRA, Bamboo, Travis CI, and so on. But the thing is you can only have public repositories for free. This is often the dilemma with open source projects–you don’t want to spend a lot of money to provide other developers your awesome new tool for free, and when you face these issues it’s a shame. I looked around for something better for me, and I found Bitbucket (also by Atlassian),  which is an awesome platform that let’s you have unlimited public AND private repositories, really nice features like the internal issue tracker (which I like more than GitHub’s), a nice Wiki and also the possibility to create your own website on Bitbucket–a feature that not many people know about and competes along with GitHub’s own similar features.

Build automation – Gradle

Java tools and technologies landscape 2014 build tool used most often graph

Do you still believe you can provide your app by building it inside your IDE? Or simply ask your team members to do it themselves? Well, you can’t! Building your app is just the first thing you have have to think about during software development. Because the longer you wait to make choices, the more painful your deployment will be. Thinking about how your app will be built is critical, and for that you should choose a build automation tool.

In the world of enterprises, you frequently just find Maven. Before Maven 1 in 2004 after being in beta/RC for two years, we had Ant and Ivy. Maven 2 came out in 2005 and version 3 in 2010, so who says we’ve been waiting JDK7 for so long?

I have to admit that Maven does its job (nearly ⅔ of developers are using it) and most companies have adopted it as a kind of standard nowadays. Personally, I don’t really like Maven because it’s 2014 and I think XML is not the best way to configure your build automation process. It was nice some years ago, but no longer for me.

Screenshot 2014-06-26 17.46.09

That’s the reason why I looked at Gradle. Used by about 1 in 10 developers and growing rapidly, Gradle requires you to break your monogamy with Java and learn some Groovy basics to use it. I have to say that I’m very excited about this build automation tool. You have a lot of flexibility to redefine your own workflows for building your app–in my case, it’s great that I can call some JavaFX tool for creating my app, or integrate a specific Git commit ID in my manifest for some reason.

But what I also like with Gradle is the possibility to develop your own plugins to fulfill your needs even if there are already a lot of available. For instance, I started creating my own plugin for building a JavaFX app by calling some executables (createjar). And believe me, it is really easy.

From what I’ve seen, there is also a lot of developer enthusiasm about Gradle (nearly 60% of developers surveyed said they wanted to learn more about Gradle) which for me has all qualities to be the next standard in build automation.

Build platform – Shippable

Everybody should know about Jenkins and Hudson for doing continuous integration. I like these options, but as a software developer doing some open source projects as a hobby, I don’t want to have to deal with a server to manage and configure for continuous integration. In the days where almost everything is “as a service” I would like to have “continuous integration as a service”.

But I also have another prerequisite, which is the connectivity to my Git repositories on Bitbucket. If you have chosen GitHub you will have the fabulous Travis CI which runs a build each time you push code to GitHub (all for free).


But if you’re using Bitbucket like I do, it’s a bit more complicated to find this service. But fortunately, I’ve found two: and Shippable. Both are nice and Bitbucket “connectable”, sending you notifications when your builds are passed or not, letting you add badges to your repos for showing the status and so on. The former,, allows you to deploy your artifact on platforms like Heroku.

I choose Shippable, because it’s based on Docker, another tool I like, and it has a nice output for the build result without providing as many configuration options in the UI as does With Shippable, you have to create a file, shippable.yml, that indicates which JDK you want, what you want to execute before and after the build, and so on. The big advantage of this is that the build configuration is under source control while on it is not because all of these options are chosen in the UI.

Deployment platform – LiveRebel

Why should a developer care about release management and deployments? That’s a great question, and one that deserves some further discussion. Some developers feel, like this author does, that “Developers should stop whining and start owning their application releases“.


And I think there is something to be said for developers taking responsibility for their code once it goes live. That said, I haven’t been able to fully evaluate different deployment platforms or release management tools. However, for developers who are serious about this, I like what I’ve seen with LiveRebel. It’s a deployment tool kind of made for Ops people, but created by developers for developers too. You should take a look at it.

Publishing platform – Bintray

Screenshot 2014-06-26 17.51.25

Once your code is built and tested, you have to think where to publish it. Indeed, putting your WAR or JAR file on a strange website or your blog isn’t always the best solution for several reasons:

  • How will you manage versions? By creating a folder for each version? It can be done, yes, but has been out of fashion since the 1980s.
  • How will you share it with others? Imagine it is a very beautiful hand-crafted API for doing the most awesome thing on earth and all users over the world use Gradle to retrieve it in their code. Would you tell them to go to your single page blog to get it? I don’t think you’ll be very popular.

Back in the day, everybody would publish their artifact in Maven central right? This seems a bit old-fashioned to me, since there is Bintray from JFrog that allows you to host your binaries in a repo that manages versions. And what is really cool is that you can publish and get your binaries directly from Gradle. That’s nice, isn’t it?

What should you do now?

I know that this article might be controversial. You could easily say that “Maven is a standard and it will be used for many years”, which is true in some ways. I have never said, nor will I ever say “Guys, we already have a de facto solution, so there’s no NEED to change”. Nope. Hell no.

I’m a developer, with passion, and I want to discover new things. And it’s because there are plenty of developers out there that things will change. I don’t like Maven, so I decided to try Gradle, and loved it. With it, I discovered Groovy, some new practices and so on. I don’t take technology for granted and as developer I want to have things done easily, based on a full stack of services that can help produce better stuff.

The most important point I’m trying to make here is that a developer is not always just a developer (maybe a “developer+”?) and the code they produce goes far beyond the commit. If your code is not well tested and well integrated, when it gets to production you will have a lot of customer complaints and that’s sucks. Learning about new tools and practices like the ones mentioned in this article is a new beginning, because as developer you can naturally play around with a lot of easy-to-configure tools that create a chain of success that tests, integrates and publishes your code.

It may be difficult to do the shift in your company; but difficult is not impossible. Just like me, be the one at work who’s suggesting something new instead of complaining about all those tools you don’t like. And if you don’t succeed in convincing your managers, do open source without them anyway. The code is in your hands! :)

The graphics presented in this article were originally published on May 21th, 2014 in the Java Tools and Technologies Landscape for 2014. For the complete 60-page report, just click on the shiny button below here…



No Responses

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.