Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Continuous Build: Is it Time to Start Using This by Default?

DZone's Guide to

Continuous Build: Is it Time to Start Using This by Default?

One of the most important parts of "Build Happiness" is the state of flow. Check out this quick update on Continuous Build in Gradle 2.11.

· DevOps Zone ·
Free Resource

Is the concept of adopting a continuous everything model a daunting task for your fast moving business? Read this whitepaper to break down and understand one of the key pillars of this model in Continuous Governance: The Guardrails for Continuous Everything.

We wanted to give you a quick update on Continuous Build in Gradle 2.11.

Build Happiness and Flow

One of the most important parts of "Build Happiness" is the state of flow. We feel that quick feedback on changes is more important than just decreasing the time spent waiting for a build—it is about creating an immersive and creative developer experience. A key piece of infrastructure for this is the Gradle Daemon, a process that runs all the time. The Daemon allows developers to speed up their build by avoiding the cost of spinning up a new Java Virtual Machine (JVM) each time a build is run. You can run the Gradle Daemon with or without Continuous Build, so you can gain a lot of benefit from just running with the Gradle Daemon. But, let’s have a look at some of the changes introduced to Continuous Build in the recent Gradle 2.11 release that make it even more compelling.

We first introduced continuous build in Gradle 2.5. It greatly reduced the feedback loop when making changes to your software by relying on Gradle to detect changes and to automatically rebuild your project. Continuous build came with a big limitation at first, as Gradle would only detect changes to source files after a build had completed. If your project’s build times were long enough, you could easily make changes during build execution and have to make another change to get Gradle to re-execute.

swearing_Gradlelephant_navy

With Gradle 2.11, we have removed this limitation from continuous build. Gradle now detects changes to source files as soon as a task begins execution. If changes are detected during the build, Gradle will complete the current build in progress and then immediately start another one. An abbreviated list of file changes is displayed to make it easy to see what caused the build to re-execute.

Here’s a quick demo of what it looks like:

Time to Upgrade to Continuous Build?

This change is important for projects large and small because it will enable users to continue working even during build time. This change affects your "flow state" because it allows you to work in a more natural manner at your own tempo instead of relying on a deeper understanding of the quirkiness of continuous build.

We suggest most developers turn on the Gradle Daemon to get the fastest build times. The continuous build experience can be even smoother and more flowing by avoiding the manual step of starting a build. We suggest that you try it out and see if it contributes to your Build Happiness.

Upgrade to Gradle 2.11 to give this a try yourself.

What’s Next

We at Gradle are committed to creating the best build system in the world, and we continue to work on features like Continuous Build to improve the developer experience. We are also working hard on a deeper software model, improved IDE integration and on a variety of performance improvements to Gradle overall. In addition to all of the above, we continue to work on Gradle.com the commercial SaaS offering that complements the Gradle open source project. Thank you for your continued support and interest in Gradle.

Are you looking for greater insight into your software development value stream? Check out this whitepaper: DevOps Performance: The Importance of Measuring Throughput and Stability to see how CloudBees DevOptics can give you the visibility to improve your continuous delivery process.

Topics:
gradle ,continuous build ,continuous delivery

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}