Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

Why Devs <3 CI: A Guide to Loving Continuous Integration

ZT Founder & Director of Engineering Toomas Römer was so excited to introduce this report, he asked his t-shirt to do it for him

Part I: Introduction

“A man who dares to waste one hour of time has not discovered the value of life.”
     -Charles Darwin, creator of the Theory of Evolution by Natural Selection

In most Java organizations, spending your time wisely when developing & deploying your apps to production is not only a major business priority, but an essential need to maintain existence in the future world of software.

Do developers care how they spend their time?

According to ZeroTurnaround’s Developer Productivity Report, the #1 aspect of the coding life that keeps developers up at night is Making Deadlines. Therefore, shouldn’t we worry about getting them the best tools, technologies and methodologies for not only meeting deadlines, but delivering the best quality software possible as well?

Software developers value their precious time and need to have organizational support in selecting the right tool set and best practices to optimise their work. This report focuses on Continuous Integration (CI) and how it enables devs to automate & speed up certain processes as well as sleep better at night by eliminating hassles often caused by long integration cycles: broken builds, manual merging hell and regressions.

Continuous Integration should be orbiting your Java ecosystem

Before we go any further, let’s give a quick definition and overview of what Continuous Integration (CI) is and why it should be a mandatory part of your Java ecosystem.

Continuous Integration is a software development practice of performing software integration frequently…several times a day, in fact. Ideally, your software application or system should be built automatically after each commit into a shared version control repository. Upon each successful build, the system integrity should be verified using automated tests that cover if not all, then at least most of the functionality. If some tests fail, the developer responsible is notified instantly and the problem can be identified and solved quickly. Using this approach, you can deliver working and reliable code to the customer much faster, while also mitigating the risk of releasing unstable, buggy software to your users.

Continuous Integration as a working concept is not exactly new, and there are going to be plenty of developers out there wondering why RebelLabs is beating what they consider to be a dead horse.

Yet when we talk to developers from all over the world at Java events, JUG meetups and speaking tours, we are continuously (no pun intended) surprised to learn that CI isn’t as widespread as we would expect – indeed, at most only 49% of developers surveyed in the Developer Productivity Report admitted using CI tools of any kind.

A Little Background About CI

Continuous Integration originates as one of the practices of Extreme Programming (XP) from the late 1990s. However, similar approaches were used earlier in mission-critical software projects, for example, by NASA. Early adopters of Continuous Integration were Kent Beck and Martin Fowler, who both published famous material on the subject matter (Beck’s book “Extreme Programming Explained” and Fowler’s “Continuous Integration” article).

Things have evolved a great deal since then, and we now have access to a good selection of tools for building a Continuous Integration ecosystem for your Java projects. Probably the best news for Java-based projects is that the most popular of these tools are free and open source.

The first step to building a solid CI pipeline is setting up a source code/ version control management process. Highly popular choices are distributed Version Control Systems (DVCS), such as Git and Mercurial. They allow developers to work offline and commit/revert changes locally before exposing any of their code into the shared repository.

The second step in the pipeline is to set up a Continuous Integration server that is employed to manage the entire process. Your CI server is going to be your new best friend, because it is going to orchestrate the following and more for you:

  • Poll the source repository for changes
  • Execute automated builds
  • Submits binaries to your artifact repository
  • Run tests and code quality analysis,
  • Notifies developers about failures in any of the phases in the pipeline.