Hans Dockter

For our production code we apply a wealth of design values and principles. Currently this is rarely done for our builds. Yet the project automation domain, specially in the enterprise, is often at least as complex as the business domain.

The design of your build is heavily influenced and possibly constrained by the design of the build system you are using. The main focus of this talk is to evaluate those design forces of the build systems. Mostly with the help of two books: Refactoring by Martin Fowler and Domain Driven Design by Eric Evans.

The build systems under review are dramatically different and thus the design of the corresponding builds. We will talk about best practices for build design and how different build systems might support that or stand in the way, thus preventing expressive, maintainable and easy to use builds. Those differences should be a major factor when you are choosing a build system appropriate to your needs.

The speaker is the founder of Gradle. So there might be some bias :). But the design principles referred to are core principles fully accepted by the Java community. The way they are violated is astonishingly obvious once pointed out. Production code would not get away with this and neither should builds.

For our production code we apply a wealth of design values and principles. Currently this is rarely done for our builds. Yet the project automation domain, specially in the enterprise, is often at least as complex as the business domain.

The design of your build is heavily influenced and possibly constrained by the design of the build system you are using. The main focus of this talk is to evaluate those design forces of the build systems. Mostly with the help of two books: Refactoring by Martin Fowler and Domain Driven Design by Eric Evans.

The build systems under review are dramatically different and thus the design of the corresponding builds. We will talk about best practices for build design and how different build systems might support that or stand in the way, thus preventing expressive, maintainable and easy to use builds. Those differences should be a major factor when you are choosing a build system appropriate to your needs.

The speaker is the founder of Gradle. So there might be some bias :). But the design principles referred to are core principles fully accepted by the Java community. The way they are violated is astonishingly obvious once pointed out. Production code would not get away with this and neither should builds.

We will look at common patterns for building larger software stacks and discuss their advantages and disadvantages. We will also present a new build and promotion patterns that scales even with very large software stacks and allows you to integrate as early as possible but at the same time keep the delivery pipeline for new features flowing.

This is a critical problem for many teams. The presenter will share many stories of real life projects, how they were affected by a dysfunctional pipeline and what it took to improve their situation. There are quite a few larger projects for which a naive practice of early integration between their components lead to constant breakages and a defect delivery pipeline. Thus they were not capable to successfully build a new version of the software stack for days or even weeks. Obviously the problem of that is dramatic as no regular manual testing and capacity testing is taking place. Not only is this a massive waste of testing resources, it also leads to very long and therefore expensive feedback cycles that severely affect your time-to-market of new features. It also a likely source of conflict between the CI team and software development, as with no other means at hand, there is a desire to create stability by not adding new features or doing important refactorings.

In this keynote, you will learn why DPE is the most important development in the software engineering world since the introduction of Agile and DevOps concepts and tools. DPE is a new software development practice that uses acceleration technologies to speed up the software build and test process and data analytics to make troubleshooting more efficient. The ultimate aim is to achieve faster feedback cycles, more reliable and actionable data, and a highly satisfying developer experience.

Hans Dockter is pioneering DPE as a practice and set of technologies and is the world’s leading advocate. Specifically, Hans will provide an overview of the key concepts and tools, business impact on key business objectives like time-to-market, cost and quality, the business case for DPE, and the role of AI/ML in DPE moving forward.

In this talk we will cover many Gradle power features that are particularly helpful for the real heavy lifting often needed in enterprise builds.

We will start this session with the concept and advantages of autowiring the Task Dependency Graph based on the inputs and outputs. We will then talk in detail about the new dependency management features such as the new cache, customizable dynamic revision handling and customizable version conflict resolution. From there we'll explore the new extension mechanism for the Gradle DSL and introduce the Gradle daemon. We will also discuss our take on best practices for dealing with module dependencies in the enterprise and how this can be mapped with Gradle. Finally we will show how you can programatically customize the way the Gradle build model is mapped to the STS Gradle Eclipse plugin. All those features are presented in the context of our roadmap and what further improvement you can expect with future releases.

The Gradle development team have not been taking it easy since the release of Gradle 1.0. New features and innovations are constantly being added, rough edges are being smoothed and the platform continues to expand. In this session we’ll explore the most notable additions to Gradle since the release of 1.0 and preview some of the new and exciting features just over the horizon with Gradle founder and Gradleware CEO Hans Dockter and Gradle core developer Peter Niederwieser.

Gradle continues to evolve with a high velocity to gain new capabilities, features and increased build performance.

We’ll dig into to some of the features incorporated since the 1.0 release, such as:

• Maven import and archetype support
• Parallel task execution
• Improved Dependency Reporting
• Dependency management improvements that make Grade the best dependency system out there.
• Additions to the task model like soft dependencies and finalizer tasks.
• Gradle Android and C/C++ Support
• Improvements to the Tooling API (i.e. embedded Gradle)
• Better scalability for large scale enterprise builds
• Using Jenkins slaves for distributed test execution.
• Deep integration with Arquillian for deploying to web and JEE servers.

We’ll also take a sneak peak at some of the upcoming features that will soon be available in Gradle.

One of the biggest impediments to overall developer productivity and the overall success of the software organization is inefficient processes. Without the right tooling to get to the root of the problem, debugging build and test failures is incredibly frustrating and leads to delays in shipping software.

In this workshop, you’ll work through examples using Maven, Gradle, and Gradle Enterprise on our real data and that of some popular open source projects. You'll learn how to measure build speed and reliability, which metrics are important, how to apply these analyses to your own builds, and how to use build caching to make those builds dramatically faster enabling your team to achieve better developer productivity.

We have seen quite a few larger projects for which a naive practice of early integration between the components lead to constant breakages. Thus they were not capable to successfully build a new version of the software stack for days or even weeks. Obviously the problem of that is dramatic as no regular manual testing and capacity testing is taking place. Not only is this a massive waste of testing resources, it also leads to very long and therefore expensive feedback cycles that severely affect your time-to-market of new features. It also a likely source of conflict between the CI team and software development, as with no other means at hand, there is a desire to create stability by not adding new features or doing important refactoring.

We will present patterns on how to integrate as early as possible but at the same time keep the delivery pipeline of new features flowing. Obviously automation can't solve all the problems of software development. But it can for example help to shield against pockets of problematic pieces of software. With a good reporting it can also give valuable insights into potential organizational problems.

Builds and Buildsystems have been treated for many years not with the conceptual depth and principles they deserve and require. The lack of this is even more painful today as modern builds form a crucial part of a modern continuous delivery pipeline far away from the simple copy, compile and archive of the past. When builds and build systems are discussed and argued about often a lot of terminology is thrown in like imperative, declarative, standardization and directed acyclic graph without having a clear definition and in-depth concept. In this session we will shed a lot of light into the dark with surprising results that are crucial to understand which build system serves your purpose.

You will learn in this session :

• What are declarative and imperative build and build systems? Followed by an in-depth discussion about advantages and dangers of both approaches.
• Why Maven is more imperative than you might think
• Gradle’s state of the art declarative approach shown by example of the new Gradle based Android build system.
• Why and what it means that builds should focus as much on developer productivity as on enforcing the software factory.
• The sweet spot in between standardization, declarativeness and necessary flexibility.
• Why also smaller projects should care about build system concepts (the larger ones don’t really have a choice.)

This talk is driven by many examples from Gradle, Maven or Ant builds.

“Software is eating the world” means all innovations in the company must be channeled through software. Developers are the fuel of this innovation. But can your talented software development team perform at its full potential?

The paradox of a successful software team is that as the codebase and team sizes grow - it becomes harder for developers to maintain the quick feedback cycles that are necessary to work creatively and productively. Compared to other industries, the software development process is in the dark ages, with little data to observe and optimize the process itself. Symptoms of this problem include not only wasted time waiting for builds, CI, IDE’s to do their job, but it also saps our creative flow - limiting early feedback cycles and creating incorrect signals like flakey tests.

Join Hans Dockter, founder and CEO of Gradle for a discussion of how you can use data from across the development process to understand what breaks your codebase and how to speed up cycle times to enable developers to remain creative and innovative even as your code base grows.