Develocity: The Complete Beginner-to-Advanced Tutorial

A practical self-study course covering Developer Productivity Engineering, Build Scan, Build Cache, build acceleration, test optimization, architecture, deployment, integrations, security, and enterprise operations.

28 chapters | Beginner to advanced | Hands-on labs

About this course

This tutorial teaches Develocity from the ground up. You do not need prior experience with Develocity, Gradle, build optimization, or Developer Productivity Engineering.

You will learn how software builds work, why they become slow and unreliable, how Develocity observes and accelerates them, and how to apply its capabilities in real development and Continuous Integration/Continuous Delivery (CI/CD) environments.

Technical verification: October 28, 2026.

The official sources confirm:

Component	Verified version or status
Develocity platform	2026.3 release family
Latest documented server patch	2026.3.3
Develocity Gradle plugin	4.6.1
Develocity Maven extension	2.6.1
Free learning option	Public Build Scan service
Private enterprise deployment	Managed service or licensed self-hosted installation
Supported build integrations	Gradle, Maven, sbt, Bazel, npm, Python, and Docker, with integration-specific capabilities

Develocity 2026.3 was released on September 24, 2026. The Gradle plugin and Maven extension versions above were released on October 20, 2026.

Important distinction: The free public Build Scan service is excellent for learning, but it is not a free self-hosted Develocity server. The main labs use a local computer and a public sample project. Enterprise deployment exercises require access to a licensed or trial instance.

Part I — Understand the World Before the Tool

Chapter 1. The Big Picture

1.1 The problem: Why does software take so long to build?

Imagine a software development team building an Android application.

The application contains hundreds of thousands of lines of code. Developers regularly change source files, add libraries, fix defects, and run automated tests.

Before they can verify the application, several activities must happen:

Source code must be compiled into executable form.
External libraries must be downloaded or located.
Application resources must be processed.
Automated tests must execute.
Application packages must be assembled.
Build results must be reported.

These activities collectively form a software build process.

A small application might build in seconds. A large application can take many minutes, especially when it includes multiple modules, extensive tests, or expensive toolchains.

The problem becomes significant when builds run hundreds or thousands of times per day.

1.2 A relatable analogy

Imagine a restaurant preparing the same meal for 100 customers.

Without an efficient process, the kitchen repeatedly washes, cuts, and prepares identical ingredients for every order.

A smarter kitchen would prepare reusable ingredients once, organize cooking steps, and identify where delays occur.

Software development has similar opportunities.

Restaurant activity	Software equivalent
Ingredients	Source code, libraries, configuration
Recipe	Build configuration
Cooking steps	Compilation, testing, packaging
Chef	Build tool
Prepared ingredients	Cached build outputs
Kitchen performance report	Build Scan
Kitchen manager improving the process	Developer Productivity Engineer

The analogy has limits: unlike cooking, software build outputs can often be reused exactly when the relevant inputs and execution conditions match.

1.3 What happens in a typical software development environment?

YesNoDeveloper changes codeBuild tool startsResolve dependenciesCompile source codeRun automated testsTests pass?Package applicationBuild succeedsBuild failsDeveloper investigates

The developer must investigate when something fails. Traditional console logs help, but they often make it difficult to understand the underlying cause.

The build might fail because of a missing dependency, incompatible compiler, incorrect configuration, test failure, network problem, or resource exhaustion.

Without detailed observability, engineers may spend significant time trying to reproduce failures.

1.4 Why traditional solutions are insufficient

Historically, developers relied on:

Terminal output and log files.
Local build reports.
Manual comparisons between successful and failed builds.
CI job histories.
Scripted performance measurements.
Build tools’ built-in caching mechanisms.

These mechanisms remain useful.

However, they do not always provide a centralized, searchable history of build behavior across developers, machines, and CI environments.

A developer might discover that a build takes 12 minutes on their laptop but only 4 minutes in CI, without knowing which tasks, dependencies, or environmental differences explain the gap.

1.5 Where Develocity fits

Develocity is designed to make software build and test execution more observable, efficient, and reliable.

It can help engineering teams:

Investigate build and test failures.
Understand where build time is spent.
Share build diagnostic information.
Reuse previous build outputs.
Analyze historical build performance.
Identify flaky tests.
Optimize test execution.
Improve build infrastructure efficiency.

This engineering discipline is commonly called Developer Productivity Engineering (DPE).

DPE treats developer productivity as an engineering problem that can be investigated and improved using evidence rather than assumptions.

What You Should Understand Before Moving On

A build is a sequence of activities that transforms source code into tested software artifacts. Problems arise when those activities are slow, repetitive, unreliable, or difficult to diagnose.

Develocity helps teams understand and improve this process, but it does not replace the build tools performing the work.

Chapter 2. Prerequisite Concepts

Before learning Develocity, you must understand the following concepts.

Concept	Simple meaning	Analogy	Importance
Source code	Human-written application instructions	Recipe	Essential
Compiler	Converts source code into another executable representation	Cooking equipment	Essential
Build tool	Automates build activities	Kitchen workflow manager	Essential
Dependency	External software required by a project	Ingredients purchased from suppliers	Essential
Build task	One defined unit of build work	Chop vegetables	Essential
Build artifact	Output produced by the build	Finished meal	Essential
Automated test	Software that checks expected behavior	Quality inspection	Essential
Cache	Stores reusable results	Prepared ingredients	Essential
Build Scan	Diagnostic record of a build	Kitchen activity report	Essential
CI/CD	Automated integration and software delivery workflows	Automated production line	Helpful
Build agent	Computer executing build jobs	Kitchen workstation	Helpful
Observability	Ability to understand system behavior from evidence	Kitchen monitoring	Essential
Deterministic execution	Same relevant inputs produce the same outputs	Repeatable recipe	Essential for caching
Distributed execution	Work runs across multiple computers	Several kitchens sharing work	Advanced

2.1 What is a build tool?

A build tool automates activities needed to produce a working application.

Common examples include:

Gradle — widely used for Java, Kotlin, Android, and other software projects.
Apache Maven — widely used for Java projects.
Bazel — used for builds involving large, frequently changing codebases.
sbt — commonly used with Scala projects.

For example, running the following command in a suitable Gradle project asks Gradle to execute the tasks associated with building the project.

./gradlew build

Here:

./ means run the file in the current directory on Unix-like systems.
gradlew is the Gradle Wrapper script.
build is the requested task.

The Gradle Wrapper allows projects to specify and download a particular Gradle version instead of relying on whatever version happens to be installed globally.

2.2 What is a software dependency?

Suppose your application uses an external library to process JSON.

Rather than implementing JSON processing yourself, your application declares a dependency on that library.

The build tool resolves the dependency, normally by downloading it from a repository.

A repository is a storage service containing published software packages.

Examples include Maven Central and private artifact repositories.

2.3 What is caching?

Consider a task that compiles 100 source files.

If none of its relevant inputs has changed, compiling them again may be unnecessary.

A build cache stores previously generated outputs so they can be reused.

YesNoBuild task requestedCalculate cache keyMatching cache entry?Restore outputsExecute taskStore eligible outputsContinue build

A cache key is an identifier calculated from information relevant to the result of a task, such as its implementation and declared inputs.

If the information matches a previous execution, eligible outputs may be reused.

But not every task is cacheable. A task that depends on undeclared files, current time, external state, or nondeterministic behavior may produce incorrect cached results.

2.4 Four concepts beginners commonly confuse

Concept	What it does	When useful
Incremental build	Processes only the inputs that need updating	Small source-code changes
Up-to-date checking	Skips a task when existing local outputs are still valid	Repeated build in the same workspace
Build Cache	Restores outputs produced by a previous compatible execution	Clean builds, other workspaces, CI
Configuration Cache	Reuses Gradle’s configuration result where compatible	Reducing repeated build setup time

These features are related but not interchangeable.

Develocity adds diagnostic visibility and distributed acceleration around supported build systems. Many of the underlying caching principles already exist in the build tools themselves.

2.5 Why is observability important?

A build log might tell you that a task took 45 seconds.

A more detailed analysis could help determine whether the delay came from compilation, configuration, dependency resolution, waiting for resources, or cache operations.

This distinction matters because each cause requires a different solution.

Making a task cacheable will not necessarily solve a slow dependency download. Adding CPU may not solve a network bottleneck.

The objective is to find the actual problem before changing the system.

Chapter 3. Essential Terminology and Glossary

Term	Full form, if applicable	Simple meaning	Example	Why it matters
DPE	Developer Productivity Engineering	Engineering practices for improving development efficiency	Reducing CI delays	Core domain
Build Scan	Product name	Detailed diagnostic record of one build	A failed build report	Troubleshooting
Build Cache	—	Reusable build outputs	Cached Java compilation	Performance
Local Cache	—	Cache stored on one computer	Gradle user-home cache	Local acceleration
Remote Cache	—	Cache shared over a network	Enterprise build cache	Cross-machine reuse
Task	—	Unit of build work	compileJava	Performance analysis
Goal	—	Maven execution unit	compiler:compile	Maven analysis
Cache Hit	—	Requested cached result exists	Output restored	Performance
Cache Miss	—	Requested result is unavailable or unsuitable	Task executes	Optimization
Cacheability	—	Whether a task can safely reuse outputs	Cacheable compiler task	Correctness
CI	Continuous Integration	Automated building and testing of changes	GitHub Actions	Automation
CD	Continuous Delivery or Deployment	Automated software release preparation or deployment	Release workflow	Delivery
Flaky Test	—	Test with inconsistent results under apparently equivalent conditions	Sometimes passes, sometimes fails	Reliability
Test Distribution	—	Runs supported tests across multiple agents	Parallel test execution	Acceleration
PTS	Predictive Test Selection	Chooses tests likely to be relevant to code changes	Testing modified components	Acceleration
JVM	Java Virtual Machine	Runtime environment used by Java and many JVM languages	Running Gradle	Compatibility
JDK	Java Development Kit	Tools for compiling and running Java software	JDK 21	Installation
HTTPS	Hypertext Transfer Protocol Secure	Encrypted web communication	Secure Develocity URL	Security
TLS	Transport Layer Security	Protocol protecting network communication	Server certificate	Security
API	Application Programming Interface	Interface used by software to communicate with software	Querying build data	Integration
RBAC	Role-Based Access Control	Permissions assigned through roles	Developer vs administrator	Security
SSO	Single Sign-On	Centralized user sign-in	Enterprise identity provider	Authentication
Kubernetes	—	Platform for operating containerized applications	Hosting Develocity	Deployment
Helm	—	Kubernetes application package manager	Installing Develocity chart	Operations
Edge	Product component	Distributed caching component near build agents	Regional cache deployment	Performance

The terminology will appear throughout the course. Learn the first ten concepts before moving to advanced deployment topics.

Chapter 4. How Software Builds Work Without Develocity

4.1 A traditional development workflow

Consider a team using GitHub, Gradle, and a CI platform.

A developer changes application code and pushes it to a repository.

The CI system downloads the project, starts a build, downloads necessary dependencies, compiles the application, runs tests, and packages the output.

DeveloperGit repositoryCI workflowBuild agentGradle or MavenDependency repositoryCompilationTestsApplication artifactConsole logsManual troubleshooting

The arrows describe the following sequence:

The developer submits code.
The repository triggers the CI workflow.
The CI platform allocates a build agent.
The build tool resolves dependencies.
Compilation and tests run.
The build produces artifacts and logs.
Engineers investigate the logs when something goes wrong.

4.2 What makes builds slow?

Build duration depends on multiple factors.

Source of delay	Example	Typical investigation
Compilation	Large Java module	Task duration
Dependency resolution	Slow artifact repository	Network and dependency timing
Testing	Thousands of automated tests	Test-duration breakdown
Configuration	Expensive Gradle plugins	Configuration-phase timing
Hardware	CPU or memory contention	Resource utilization
Caching	Repeated execution of reusable work	Cache hits and misses
Network	High-latency remote services	Request timing
CI environment	Every build starts on a clean runner	Cache availability

4.3 Why faster hardware is not always the answer

Suppose a build takes ten minutes:

Two minutes resolving dependencies.
Four minutes compiling.
Three minutes testing.
One minute packaging and other work.

Buying a larger machine might accelerate compilation, but it may not substantially improve slow dependency downloads.

Likewise, caching a compilation task might reduce execution time without eliminating expensive test execution.

The correct optimization depends on knowing where time is spent and which work can safely be avoided.

4.4 The measurement principle

Build optimization should follow a continuous engineering loop:

YesNoMeasureIdentify bottleneckForm hypothesisMake one changeMeasure againImproved?Keep and monitorReconsider

This cycle is important independently of Develocity.

A performance optimization is meaningful only if its effect can be measured, validated, and maintained.

Part I outcome: You now understand the underlying problem. The next step is to learn how Develocity helps engineers investigate and improve build execution.

Part II — Understand Develocity

Chapter 5. What Is Develocity?

5.1 The simplest definition

Develocity is a software build and test observability and acceleration platform.

It helps software engineering teams understand build execution, troubleshoot failures, analyze performance, and avoid unnecessary work.

Develocity is developed commercially by Gradle, Inc., which now also uses the Develocity brand.

5.2 Beginner-friendly explanation

Suppose you have a CI pipeline that frequently takes 20 minutes.

You want to know:

Why does it take 20 minutes?
Which parts are slow?
Are the same tasks unnecessarily executed repeatedly?
Why did yesterday’s build fail?
Why does the build succeed locally but fail in CI?
Can some tests be avoided or distributed?
Are developers experiencing the same problems?

Develocity helps answer these questions by collecting and analyzing information from supported build tools.

5.3 Technical definition

Develocity is an integrated platform for ingesting, storing, analyzing, and presenting build and test execution telemetry, with associated services for build caching, test acceleration, and developer productivity optimization.

The platform interacts with supported build tools through plugins, extensions, and agents.

5.4 Is Develocity the same as Gradle?

No. This distinction is fundamental.

Gradle Build Tool	Develocity
Executes build tasks	Observes and analyzes build executions
Compiles and packages applications	Collects and presents diagnostic information
Runs supported test tasks	Analyzes results and execution behavior
Provides built-in local caching	Provides centralized and distributed caching capabilities
Open-source build automation tool	Commercial platform with a free public Build Scan service
Can work independently	Requires compatible build integrations for build telemetry

You can use Gradle without Develocity.

You can also use Develocity with other supported build systems without using Gradle as your build tool.

5.5 Where does Develocity run?

Develocity has two important sides.

Client side: A plugin, extension, or agent integrates with the build process. The developer or CI runner may be using Windows, macOS, or Linux, subject to the requirements of the particular build integration.

Server side: Develocity operates as a service that collects and analyzes build data. Supported deployment options include managed cloud services and self-hosted Linux/Kubernetes infrastructure.

Its self-hosted server is not a conventional desktop application installed with Homebrew, apt, or a Windows installer.

5.6 What Develocity does not replace

Develocity is not:

A source-code management system like Git.
A CI orchestrator like Jenkins.
A general-purpose compiler.
A replacement for Gradle, Maven, or Bazel.
A source-code vulnerability scanner.
A complete monitoring replacement for Prometheus.
A guarantee that all builds are reproducible.
A guarantee that every build or test will become faster.

It complements existing tools instead of replacing their core responsibilities.

Chapter 6. Why Does Develocity Exist?

6.1 The cost of slow feedback

Consider a team of 40 developers. Each developer runs 12 builds per working day.

If every build takes 8 minutes: [ 40\times12\times8=3{,}840\text{ build-minutes/day} ]

That represents 64 hours of combined build execution per day.

These are illustrative numbers, not measured Develocity performance data. Builds can run in parallel, and not every minute of build execution is a minute of developer waiting.

But the calculation demonstrates why repeated build work matters.

6.2 Three realistic scenarios

Scenario	Without Develocity	With Develocity
CI builds becoming slower	Engineers manually inspect logs and timings	Build Scan and historical performance data help locate regressions
Different builds of identical code	Teams investigate machine differences manually	Build comparison highlights configuration, dependency, input, and environment differences
Repeated compilation across runners	Multiple agents repeat compatible work	Remote Build Cache can reuse eligible outputs

6.3 What benefits are realistic?

Develocity can reduce investigation time by making detailed execution data available.

Caching can reduce computation when compatible outputs already exist.

Test Distribution can reduce the elapsed time of suitable test workloads by running work across multiple agents.

Predictive Test Selection can shorten a feedback cycle by executing tests selected as relevant to the change.

However, actual gains depend on workload characteristics, task cacheability, network performance, available agents, and organizational configuration.

6.4 Trade-offs

Develocity also introduces costs and responsibilities:

Commercial licensing.
Server or managed-service operating costs.
Integration and onboarding effort.
Storage consumption from build telemetry.
Network traffic for Build Scan uploads and cache transfers.
Security and access-control responsibilities.
Configuration and compatibility management.

An organization should compare these costs against the improvements it actually measures.

6.5 When Develocity is unnecessary

A single developer working on a tiny project might already have fast and reliable builds.

In that environment, Gradle’s built-in diagnostics and local cache may be sufficient.

Similarly, if a project primarily needs source-code quality analysis or application runtime monitoring, Develocity does not directly solve those needs.

Practical rule: Start with a measurable build or test problem, then select the smallest intervention capable of solving it.

Chapter 7. How Develocity Works

7.1 Fundamental operating model

A Develocity integration operates alongside the build tool.

The build still executes through Gradle, Maven, or another supported system.

The integration collects supported diagnostic information and sends it to a Develocity service, where it can be viewed and analyzed.

When caching is configured, supported tasks can also retrieve or store reusable outputs.

YesYesNoNoDeveloper or CIGradle buildDevelocity Gradle pluginExecute build tasksCacheable task?Cached output available?Restore task outputExecute taskStore eligible outputBuild resultCapture build informationDevelocity serverBuild ScanHistorical analyticsTroubleshooting

This is a simplified conceptual diagram. In actual execution, task observation and cache activity happen throughout the build, rather than only after it finishes.

7.2 The main components

Component	Responsibility
Build tool	Executes build work
Develocity integration	Collects supported build data and integrates acceleration capabilities
Develocity server	Receives, processes, and exposes build information
Build Scan	Displays an individual execution record
Build Cache	Stores reusable outputs
Develocity Edge	Provides distributed caching close to build clients
Database	Stores persistent application data
Object storage	Stores supported persistent build and operational data
Browser interface	Lets users investigate builds
API and MCP services	Enable supported programmatic and AI-agent access

MCP means Model Context Protocol, a protocol used to expose tools and information to compatible AI applications.

7.3 Understanding a Build Scan

A Build Scan is a record associated with a particular build execution.

It can contain information such as:

Build outcome.
Build start time and duration.
Invoked tasks.
Task execution timing.
Test results.
Build environment information.
Dependency details.
Build configuration.
Console output.
Cache activity.
Captured performance data.

The amount and type of information depend on the build system, integration version, configuration, and available features.

7.4 Understanding Build Cache

A Build Cache operates differently.

Instead of providing a diagnostic report, it stores outputs that can be reused when a compatible task execution is requested.

For example, imagine two CI runners compiling the same source files with equivalent task inputs.

If the first runner produces a valid cacheable output and stores it in a shared cache, the second runner may restore that output instead of recompiling.

This works only when the relevant inputs, implementation, environment constraints, and cache rules permit safe reuse.

7.5 What happens when Develocity is unavailable?

A Build Scan upload failure is different from a build failure.

A properly configured build can continue executing when telemetry publication cannot reach the server.

Remote-cache availability is another concern. If remote-cache data cannot be retrieved, work may need to execute instead, increasing build duration.

Engineers should monitor both situations, test failure behavior, and ensure that outages do not create unacceptable delays or deployment risks.

7.6 Where state lives

There are different types of state:

Source code and project configuration live in the project and its repositories.
Local build state and local cache data live on the build machine.
Shared cached outputs live in configured remote caching services.
Build telemetry and platform configuration are persisted by Develocity.
Application data and cache objects may use PostgreSQL, persistent volumes, and object storage.

The important principle is to distinguish the data used to build software from the telemetry describing that build and the reusable outputs produced by it.

Chapter 8. Core Features Explained Simply

Develocity is more than a build-report viewer, but capabilities differ by integration and license.

8.1 Essential and everyday features

Feature	What it does	Problem solved	Level
Build Scan	Records and presents build activity	Difficult troubleshooting	Beginner
Build timeline	Visualizes execution steps and durations	Unknown bottlenecks	Beginner
Test results	Displays supported test outcomes	Investigating test failures	Beginner
Performance analysis	Breaks down build activity	Slow builds	Beginner
Build comparison	Compares execution details	Unexpected differences	Intermediate
Dependency analysis	Shows resolved dependency information	Dependency-related issues	Intermediate
Custom tags and values	Adds searchable build context	Difficult build identification	Intermediate
Build history	Helps investigate repeated patterns	Performance regressions	Intermediate

8.2 Acceleration features

Feature	What it does	Example
Build Cache	Reuses outputs of compatible work	Avoid compiling unchanged inputs
Artifact Cache	Accelerates supported artifact retrieval workflows	Reduce repeated dependency fetching
Setup Cache	Reuses eligible build setup state	Speed up ephemeral CI initialization
Test Distribution	Distributes suitable test execution	Use additional test agents
Predictive Test Selection	Selects tests likely relevant to a change	Faster pre-merge feedback
Develocity Edge	Brings caching services closer to build clients	Regional CI caching

These features address different types of work. Reusing a compiled output is not the same as caching a downloaded dependency or selecting fewer tests.

8.3 Advanced and enterprise features

Feature	Purpose
Flaky-test analysis	Investigate tests with inconsistent outcomes
Failure analytics	Find recurring build and test failure patterns
Reporting and dashboards	Analyze execution trends across projects
API integration	Retrieve supported build data programmatically
MCP integration	Give authorized AI agents controlled access to build information
Build Caching Optimizer	Analyze caching problems with AI-assisted workflows
Supply-chain and provenance integrations	Support artifact traceability and governance
Trusted artifact isolation	Separate trusted and untrusted cached content
SSO and access control	Manage enterprise identities and permissions

8.4 Newer integration capabilities and limitations

The modern Develocity ecosystem has extended beyond its original JVM-oriented integrations.

For example:

Docker: Develocity 2026.3 introduced Docker Build Scan support through an agent that observes compatible BuildKit image builds. It requires enablement and has specific Docker, Buildx, BuildKit, and Java prerequisites.
Python: The Python agent provides Build Scan support for selected Python tool invocations, including pytest results. This integration is in beta and requires enablement.
npm: An npm agent captures supported npm build activity and dependency information.
AI integration: The Develocity MCP Server exposes supported diagnostic and analytical functionality to authorized AI agents.

The Python and Docker integrations should not be assumed to provide feature parity with Gradle or Maven.

8.5 Licensing and feature availability

Develocity is commercially licensed. Its pricing is organized around commercial packages and deployment models, so not every feature described here is automatically available in every installation.

The platform offers managed and self-hosted options, and its publicly advertised licensing model is based on committers. Specific commercial terms and optional feature entitlements should be confirmed before procurement.

Chapter 9. Similar Tools and Alternatives

Not every build performance tool competes directly with Develocity.

Some provide caching, some provide diagnostic information, and others provide remote execution.

9.1 Comparison

Tool	Primary purpose	Main strength	Main limitation relative to Develocity	Best use case	Relationship
Develocity	Cross-build observability and acceleration	Integrated build data, caching, and analysis	Commercial cost and operational complexity	Medium-to-large engineering teams	Reference platform
Gradle built-in diagnostics and cache	Gradle build optimization	Already part of Gradle	Less centralized historical analysis	Individual Gradle projects	Complementary
Gradle Profiler	Build benchmarking	Controlled measurement of Gradle performance	Not a full shared telemetry platform	Build performance experiments	Complementary
BuildBuddy	Bazel-focused productivity platform	Build results, remote cache, remote execution	Primarily centered on Bazel	Bazel teams	Partial competitor
EngFlow	Remote build execution and acceleration	Distributed build infrastructure	Different product emphasis and ecosystem considerations	Large Bazel-oriented workloads	Partial competitor
Nx Cloud	JavaScript/TypeScript monorepo CI acceleration	Remote task caching and distributed execution	Different primary build ecosystem	Nx workspaces	Ecosystem alternative
Maven-native tools and reports	Maven build and test diagnostics	Simple integration with Maven workflows	No equivalent unified Develocity experience by default	Small Maven projects	Complementary
Public Build Scan service	Free individual build diagnostics	Very low barrier to entry	No privately owned Develocity server or full enterprise platform	Learning and public sample projects	Free entry point

BuildBuddy provides a Bazel-oriented results interface and remote execution capabilities. Nx Cloud provides remote caching and distributed task execution for Nx workflows. Those are useful comparisons, but neither should be described as a drop-in replacement for every Develocity integration.

9.2 Which tool should you choose and why?

For learning: Start with the free public Build Scan service and Gradle’s built-in caching.

For a small Gradle project: First evaluate Gradle’s native –profile, –info, task reports, and Build Cache. Add more sophisticated tooling only when it solves a demonstrated need.

For a large Gradle or Maven organization: Develocity becomes more attractive when teams need central historical analysis, shared acceleration, and engineering-wide visibility.

For a Bazel-centric organization: Evaluate Develocity alongside Bazel-focused alternatives such as BuildBuddy and EngFlow, considering remote execution, observability, security, pricing, and operational requirements.

For an Nx monorepo: Nx Cloud is a relevant alternative because it directly integrates with Nx tasks and their caching model.

The best choice depends on your existing build system and the problem you are trying to solve, not a universal product ranking.

Part III — Architecture and Workflows

Chapter 10. Architecture Explained from Simple to Advanced

10.1 Architecture level 1: A single developer

The simplest learning setup is a local project that publishes a Build Scan to the free public service.

HTTPSDeveloper laptopGradle WrapperGradle buildBuild Scan integrationPublic Build Scan serviceBrowser report

What happens:

The developer runs a Gradle build.
The Build Scan integration captures supported information.
The information is uploaded over HTTPS.
The service provides a URL.
The developer opens the diagnostic report.

This setup requires no private Develocity server.

10.2 Architecture level 2: Small-team deployment

Now imagine a team where every developer and CI runner sends build data to one private Develocity installation.

Private DevelocityBuild clientsDeveloper ADeveloper BCI runnerBuild Scan serviceBuild Cache serviceWeb interfacePersistent data

The diagram is simplified: an actual deployment separates database storage, cache content, application services, authentication, and related components.

Advantages: Build records are centralized, teams can investigate one another’s builds according to permissions, and compatible build outputs can be shared.

Responsibilities: The organization must manage authentication, network access, backups, storage, upgrades, and security controls.

10.3 Architecture level 3: Production Kubernetes environment

Develocity’s self-hosted deployment is Kubernetes-based and distributed through Helm charts.

A production architecture may look like this:

Kubernetes environmentEngineering systemsDeveloper laptopsGitHub Actions or JenkinsRegional build agentsDNS and HTTPS ingressDevelocity applicationAuthentication servicesDevelocity EdgeTelemetry and monitoringPostgreSQLObject storageIdentity provider

Not every connection or service shown represents a mandatory direct network path. The diagram illustrates the roles of the major subsystems.

Component responsibilities

Component	Responsibility	Operational consideration
Kubernetes	Runs Develocity components	Cluster capacity and availability
Helm	Manages the installed release	Versioned, reviewed configuration
Ingress	Routes external requests	HTTPS, hostname, access restrictions
PostgreSQL	Persists application data	Backups, storage performance
Object storage	Holds supported durable data	Retention and access policy
Edge	Serves distributed cache workloads	Network locality and cache health
Identity provider	Authenticates users	SSO and account lifecycle
Monitoring	Tracks operational status	Alerts and incident response

10.4 A major architecture consideration: Edge versus legacy Build Cache nodes

Develocity’s documentation states that support for the older standalone Build Cache node component will end after 2026. Versions starting with Develocity 2027.1 will no longer support that component.

Develocity Edge is the recommended migration target.

This matters if you are designing a new enterprise deployment. Rather than introducing legacy components, use the architecture supported by the current Edge documentation.

10.5 How architecture changes as usage grows

An organization might begin with a single installation, then add:

Additional caching capacity near CI runners.
Managed database services.
Object storage.
Enterprise authentication.
Network segmentation.
Monitoring and alerting.
Backup and recovery procedures.
Project-level access control.

Scaling should follow observed workload and supported vendor architecture, not simply the number of developers.

For example, a cache located far from build agents might create enough network latency to reduce the value of reuse.

Chapter 11. The Complete Workflow

11.1 A normal build

A Gradle build connected to Develocity commonly follows this logical sequence:

A developer or CI runner invokes Gradle.
Gradle loads project configuration.
The Develocity plugin configures its integration.
Gradle determines the tasks needed.
Gradle evaluates task inputs and available cached results.
Eligible cached outputs are restored; remaining tasks execute.
Test results and other supported information are captured.
The build completes successfully or unsuccessfully.
The integration publishes a Build Scan according to its publishing policy.
Engineers inspect the resulting data.

11.2 A typical sequence diagram

BrowserDevelocityBuild CacheGradleBrowserDevelocityBuild CacheGradlealt[Cache hit][Cache miss]DeveloperRun buildConfigure and select tasksLook up eligible task outputReturn cached outputExecute taskStore output if permittedRun remaining tasks and testsPublish Build ScanReturn Build Scan URLShow build result and URLOpen URLRequest Build ScanDisplay diagnosticsDeveloper

This example assumes the cache and Build Scan services are configured and reachable.

A cache hit is not guaranteed merely because a previous build has executed. Task cacheability, input equality, cache permissions, eviction, and the current environment all matter.

11.3 Failure handling

SuccessFailureNoYesYesNoStart buildExecute tasksBuild resultCapture successful buildCapture failure detailsPublish allowed?Finish without Build Scan uploadServer reachable?Publish Build ScanReport upload problemShare report URLInspect local output

A failed build can still produce a useful Build Scan.

That is one of the important advantages of capturing execution data in both successful and unsuccessful builds.

11.4 How to verify workflow success

Check three independent results:

Verification	Success condition
Build execution	Expected tasks or tests finish with the expected outcome
Build Scan publication	A report URL is produced and the record opens
Cache operation	An eligible task shows the expected cache behavior

These checks prevent a common mistake: assuming that a successful build proves telemetry publication and remote caching are also working.

Chapter 12. Where Develocity Fits into a Larger System

Consider a modern development environment with source control, CI, dependency repositories, artifact registries, and deployment infrastructure.

DeveloperGit repositoryCI pipelineGradle or MavenDependency repositoryBuild and test executionApplication artifactsArtifact registryDeployment platformDevelocity integrationDevelocityShared Build CacheEngineering team

Solid arrows represent build and delivery activity. The dotted line represents the relationship between Develocity and its associated caching infrastructure, rather than an unconditional data transfer.

12.1 Upstream and downstream relationships

Upstream systems provide inputs to the build: Git repositories, source code, build configuration, dependencies, and toolchains.

Downstream systems receive build outputs: artifact registries, container registries, release pipelines, and deployment environments.

Develocity observes and accelerates the supported build process between these systems.

12.2 Integration examples

Develocity can be useful alongside:

GitHub Actions, Jenkins, GitLab CI, and other CI platforms.
Gradle, Maven, Bazel, and supported build ecosystems.
Internal artifact repositories.
IntelliJ-based integrated development environments.
Enterprise identity providers.
Reporting platforms and dashboards.
Authorized AI agents using the supported APIs and MCP services.

An integration does not automatically mean that Develocity configures or operates those other systems.

12.3 Responsibility boundaries

A useful operational model is:

Team	Typical responsibility
Developers	Code, tests, correct task inputs
Build engineers	Build logic, dependencies, cacheability
Platform engineers	CI runners, cache topology, deployment
Security engineers	Credentials, access policies, data governance
Operations/SRE	Service reliability, monitoring, recovery
Engineering leadership	Performance objectives and adoption metrics

Develocity provides shared evidence to these teams, but the teams still own the work required to improve their systems.

Part IV — Installation and First Success

Chapter 13. Prerequisites and Environment Preparation

There are two different ways to begin using Develocity, and they have very different requirements.

Path A — Learn locally

Recommended for beginners

Run a Gradle project on your computer and publish Build Scans to the public service.

No Develocity server or commercial license required.

Path B — Enterprise deployment

Advanced

Deploy a licensed Develocity server on supported infrastructure and connect development and CI environments.

Requires a license, infrastructure, and administration.

13.1 Minimum requirements for the local labs

Requirement	Purpose	Mandatory?
Windows, Ubuntu, macOS, or suitable Linux	Runs the development environment	Yes
Java Development Kit (JDK)	Executes Gradle and compiles Java	Yes
Git	Downloads the sample repository	Yes for the official quickstart
Internet connectivity	Downloads dependencies and publishes Build Scans	Yes
Terminal or PowerShell	Executes commands	Yes
Browser	Opens Build Scan reports	Yes
Gradle Wrapper	Runs the project’s Gradle version	Provided by quickstart
Global Gradle installation	Creates entirely new projects	Only for the later custom-project lab
Develocity commercial license	Private server access	No for public Build Scan labs

Recommended training environment: JDK 21, a modern desktop operating system, Git, and a project-supplied Gradle Wrapper.

Gradle currently requires Java 17 or later to run. JDK 21 is a convenient training choice rather than a universal requirement for every project. Project-specific builds may require another JDK version.

13.2 Local hardware

For a small Java demonstration, a conventional developer laptop with several gigabytes of free memory and storage is generally adequate. A practical recommendation is 8 GB of system RAM or more, although this is a training recommendation, not a Develocity platform minimum.

The local lab does not run a Develocity server.

13.3 Private server requirements

A self-hosted Develocity deployment is a different infrastructure project.

The official standalone installation guidance lists at least 10 CPUs and 24 GiB of memory. For a production Kubernetes installation, the published sizing guidance recommends a larger multi-node environment and additional persistent storage.

Self-hosted Develocity is deployed on supported Linux-based Kubernetes infrastructure using Helm; it is not installed as a native macOS or Windows desktop application.

Production prerequisites include:

A valid Develocity license.
Compatible Kubernetes and Helm versions.
A supported CPU architecture.
Working cluster DNS and networking.
A hostname and properly configured HTTPS.
Database and persistent storage.
Sufficient CPU, memory, and storage capacity.
Access to required container registries.
Administrative access to the intended cluster.
Backup, monitoring, and access-control plans.

For cloud infrastructure, use the current compatibility matrix before choosing Kubernetes, PostgreSQL, ingress, or storage versions.

13.4 Network considerations

For the public learning path, your machine needs outbound HTTPS access to download Gradle dependencies and publish Build Scans.

For an enterprise deployment, consider separate connections for:

Developer-to-Develocity traffic.
CI runner-to-Develocity traffic.
Build-cache uploads and downloads.
Server-to-database traffic.
Server-to-object-storage traffic.
Authentication and monitoring integrations.

A Build Scan may contain project and environment information. Do not publish confidential company builds to a public service without authorization.

13.5 Pre-installation checklist

Local lab readiness

[ ] I have permission to install developer tools
[ ] I know which operating system I am using
[ ] I can open a terminal or PowerShell
[ ] My Java installation works
[ ] Git is available
[ ] My network can reach public Gradle services
[ ] I will use only non-sensitive example source code

Chapter 14. Installation on Windows, Ubuntu, macOS, and Linux

We will install the development prerequisites first. Afterward, the same official sample project will work across the supported environments.

14.1 Windows

Recommended method: Native Windows PowerShell with a JDK and Git. Windows Subsystem for Linux (WSL) is an alternative when your project requires Linux build behavior.

Step 1 — Open PowerShell

Open Windows Terminal or PowerShell with the permissions needed to install software.

Check whether Java and Git are already installed:

java -version
javac -version
git --version

java runs Java programs; javac compiles Java source files.

If either Java command is not recognized, install a JDK.

Step 2 — Install JDK 21

On Windows systems with Windows Package Manager (winget), run:

winget install EclipseAdoptium.Temurin.21.JDK
Code language: CSS (css)

Temurin is a distribution of OpenJDK.

Close and reopen PowerShell after installation, then verify:

java -version
javac -version

Expected result: both commands display version information for the installed JDK.

If Windows still cannot find Java, check whether the installer added Java to PATH and whether JAVA_HOME points to the JDK installation.

Step 3 — Install Git

winget install Git.Git
Code language: CSS (css)

Open a new PowerShell window and verify:

git --version

Step 4 — Download the sample project

git clone https://github.com/gradle/gradle-build-scan-quickstart.git
cd gradle-build-scan-quickstart
Code language: PHP (php)

Step 5 — Verify Gradle

.\gradlew.bat --version
Code language: CSS (css)

The repository contains a Windows Gradle Wrapper, so a global Gradle installation is not required.

Expected result: Gradle displays its version and runtime information. The first execution might download the project-selected Gradle distribution.

Common Windows issues

Problem	Likely cause	Solution
java not recognized	Java missing from PATH	Reopen PowerShell and inspect JDK installation
JAVA_HOME invalid	Incorrect JDK directory	Set JAVA_HOME to the actual JDK root
git not recognized	Git not installed or terminal not refreshed	Install Git and reopen PowerShell
Wrapper download fails	Proxy, TLS, or DNS issue	Verify network and proxy configuration
Build fails on an incompatible JDK	Project requires another version	Follow the project’s JDK compatibility requirements

The commands above use PowerShell syntax, not Unix shell syntax.

14.2 Ubuntu

The following example assumes an Ubuntu release that provides OpenJDK 21 packages, such as Ubuntu 24.04.

Step 1 — Update package metadata

sudo apt update

This refreshes the package lists.

Step 2 — Install prerequisites

sudo apt install -y openjdk-21-jdk git curl unzip

The packages provide the JDK, Git, HTTP download tooling, and ZIP extraction support.

Step 3 — Verify

java -version
javac -version
git --version

Step 4 — Clone and inspect the quickstart

git clone https://github.com/gradle/gradle-build-scan-quickstart.git
cd gradle-build-scan-quickstart
./gradlew --version
Code language: PHP (php)

The ./gradlew file is the Unix Gradle Wrapper.

If your shell reports permission denied, inspect the file permissions and make sure you obtained the repository normally through Git. The Gradle Wrapper script should have executable permission in the official repository.

For corporate environments, ask your administrator to approve the project and distribution URLs rather than disabling certificate validation.

14.3 macOS

The procedure works on compatible Intel and Apple Silicon Macs, provided the selected JDK distribution supports your hardware.

Step 1 — Check installed tools

java -version
git --version

macOS may prompt you to install the Apple command-line developer tools when Git is not available.

Step 2 — Install a JDK with Homebrew

If Homebrew is already installed:

brew install --cask temurin@21
Code language: CSS (css)

Verify the installed JDK:

/usr/libexec/java_home -V
java -version
javac -version

java_home lists the JDK installations macOS knows about.

If you do not use Homebrew, install Temurin using the official macOS installer from Eclipse Adoptium.

Step 3 — Install Git if needed

brew install git

Step 4 — Clone the example

git clone https://github.com/gradle/gradle-build-scan-quickstart.git
cd gradle-build-scan-quickstart
./gradlew --version
Code language: PHP (php)

Expected result: Gradle version details appear without a Java compatibility error.

14.4 Debian, Fedora, RHEL, Rocky Linux, and AlmaLinux

Use the package system supported by your distribution and release.

For example, on a Fedora release providing OpenJDK 21:

sudo dnf install -y java-21-openjdk-devel git

On Debian-based systems where OpenJDK 21 is available through an approved repository:

sudo apt install -y openjdk-21-jdk git

Do not assume that every Debian or enterprise Linux release includes this exact package version. Confirm package availability first, and use an approved vendor JDK when necessary.

Verify with:

java -version
javac -version
git --version

For Alpine Linux, check the current project and JDK compatibility requirements before choosing a musl-based environment. The beginner labs do not require Alpine.

14.5 Operating-system comparison

Platform	Java installation example	Gradle execution	Native private server
Windows	Temurin installer or winget	.\gradlew.bat	No
Ubuntu	OpenJDK packages	./gradlew	On supported Linux/Kubernetes infrastructure
macOS	Temurin installer or Homebrew	./gradlew	No
Fedora/RHEL family	Supported OpenJDK packages	./gradlew	On compatible Linux/Kubernetes infrastructure
Debian family	Supported OpenJDK distribution	./gradlew	On compatible Linux/Kubernetes infrastructure

The operating system of a developer laptop does not need to match the operating system of the private Develocity server.

14.6 Advanced installation: A private Develocity server

This is an enterprise-only procedure. It is not required for any free learning lab.

Before proceeding, obtain the appropriate Develocity license, select a supported Kubernetes platform, configure DNS and HTTPS, and follow the official sizing and storage guidance.

A minimal illustrative Helm values file has this structure:

<em># values.yaml</em>
global:
  hostname: develocity.example.com

database:
  location: embedded

ingress:
  enabled: true
Code language: PHP (php)

Replace develocity.example.com with a hostname you control.

This file is not a production configuration. In particular, enabling ingress does not automatically create a trusted TLS certificate or establish all necessary networking and security settings.

On a workstation authenticated to the intended Kubernetes cluster, add the official Helm repository:

helm repo add gradle https://helm.gradle.com/
helm repo update gradle
helm search repo gradle/gradle-enterprise
Code language: JavaScript (javascript)

Confirm your current Kubernetes context:

kubectl config current-context
kubectl get nodes
Code language: JavaScript (javascript)

The first command identifies the selected cluster. Never run a Helm installation without checking the context.

After preparing the license file and all required infrastructure, the documented installation pattern is:

helm install \
  --create-namespace \
  --namespace develocity \
  ge gradle/gradle-enterprise \
  --values values.yaml \
  --set-file global.license.file=./develocity.license
Code language: JavaScript (javascript)

The license filename is an example placeholder for the actual file received from the vendor.

This command modifies the Kubernetes cluster, creates resources, and may incur infrastructure charges. It must be run only with appropriate authorization.

Check the deployment:

helm --namespace develocity list
kubectl --namespace develocity get pods
Code language: JavaScript (javascript)

Expected result: The release is listed and the application pods eventually report healthy or ready status.

If the pods remain unready, investigate the deployment, database, storage, image pulls, and application logs before attempting a reinstall.

The chart and installation guidance are maintained in the official Develocity documentation. Self-hosted deployments should pin and review compatible versions instead of blindly adopting the latest chart.

Chapter 15. Your First Working Build Scan

Lab 1 · Beginner · Local computer · No private server required

15.1 Objective

Build a sample Java application and publish your first Build Scan.

You will use the official Gradle Build Scan quickstart repository, which already contains the necessary Gradle integration.

15.2 What you will produce

At the end of the exercise, you should have:

A successful local Java build.
A terminal message containing a Build Scan URL.
A browser report showing that build.
A basic understanding of the report sections.

15.3 Step 1 — Download the project

macOS/Linux:

git clone https://github.com/gradle/gradle-build-scan-quickstart.git
cd gradle-build-scan-quickstart
Code language: PHP (php)

Windows PowerShell:

git clone https://github.com/gradle/gradle-build-scan-quickstart.git
cd gradle-build-scan-quickstart
Code language: PHP (php)

15.4 Step 2 — Run the build with Build Scan enabled

macOS/Linux:

./gradlew build --scan

Windows PowerShell:

.\gradlew.bat build --scan
Code language: CSS (css)

The command has three important parts:

Part	Meaning
gradlew	Runs the project-selected Gradle version
build	Executes the project’s build lifecycle
‘–scan	Requests publication of a Build Scan

On first use, Gradle may download its distribution, plugins, and project dependencies.

When asked, review and accept the public Build Scan service’s terms only if you agree to them.

15.5 Step 3 — Identify the output

Successful output will resemble:

BUILD SUCCESSFUL

Publishing build scan...
https://gradle.com/s/EXAMPLE_BUILD_SCAN_ID
Code language: JavaScript (javascript)

The URL shown above is illustrative. Your build generates its own unique URL, possibly using a newer service domain or redirect.

The public service may require email-based activation or verification before you can view the report.

15.6 Step 4 — Open the Build Scan

Open the generated URL in a browser.

Explore the information available for the build:

Summary: Did the build succeed? How long did it take?
Timeline: Which stages consumed time?
Tasks: Which tasks executed, were skipped, or reused outputs?
Tests: Which tests ran and what were their outcomes?
Dependencies: What external components did the project resolve?
Environment: Which Gradle, Java, and operating-system details were captured?

Exact navigation labels can vary by the service and integration version.

15.7 Step 5 — Run the build again

macOS/Linux:

./gradlew build --scan

Windows:

.\gradlew.bat build --scan
Code language: CSS (css)

Compare the second Build Scan with the first.

You may notice that tasks are now marked UP-TO-DATE, indicating that Gradle found no reason to repeat their work.

The second build may also avoid downloading dependencies because they are already available locally.

15.8 Step 6 — Observe a failed build

Using a code editor, open:

src/main/java/example/Example.java

Introduce a temporary Java syntax error, for example by removing a required semicolon from an existing valid statement.

Run the same build command again.

Expected result:

BUILD FAILED

The build may still publish a Build Scan with useful failure information.

Open that scan and locate the compilation failure.

15.9 Step 7 — Restore the project

Because the quickstart project was freshly cloned, you can discard your own temporary change to the demonstration file.

git restore src/main/java/example/Example.java

The same Git command works in Windows PowerShell.

Be aware that git restore discards uncommitted changes to the specified file. Do not use it on files containing work you want to preserve.

Run the build again and confirm that it succeeds.

15.10 Verification checklist

[ ] The first build succeeded.
[ ] The console displayed a Build Scan URL.
[ ] The URL opened in a browser.
[ ] You identified task execution information.
[ ] You observed a failed build and its report.
[ ] You restored the code and built successfully again.

Lab success criterion: You can independently create, open, and interpret a Build Scan for both a successful and a failed Gradle build.

Part V — Commands, Configuration, and Daily Usage

Chapter 16. Essential Commands and Operations

Develocity does not have one universal command-line interface for every build ecosystem. Most day-to-day usage happens through the existing build tool and its Develocity integration.

16.1 Gradle command reference

The following commands assume you are in a Gradle project with a compatible wrapper.

Command	What it does	When to use	Warning
./gradlew –version	Displays Gradle version and runtime	Verify setup	None
./gradlew tasks	Lists available tasks	Learn project operations	Some builds configure extensively
./gradlew build	Runs the build lifecycle	Normal development	Depends on project build logic
./gradlew build –scan	Builds and requests a Build Scan	Troubleshooting	May publish project information
./gradlew test –scan	Executes tests with diagnostic capture	Test investigation	Depends on test task configuration
./gradlew build –info	Enables more detailed logging	Diagnose execution	May reveal sensitive details in logs
./gradlew build –stacktrace	Prints failure stack traces	Diagnose errors	Can produce extensive output
./gradlew build –build-cache	Enables Gradle Build Cache for the invocation	Cache experiments	Task behavior still depends on cacheability
./gradlew clean build –build-cache	Removes build outputs, then rebuilds with caching	Compare cache reuse	clean deletes generated build outputs
./gradlew build –no-build-cache	Builds without Gradle task-output caching	Isolate cache effects	Usually slower
./gradlew build –configuration-cache	Requests configuration caching	Diagnose setup overhead	Plugins/build logic must be compatible
./gradlew clean	Deletes generated project build outputs	Clean-build test	Can remove outputs you still need

On Windows PowerShell, substitute .\gradlew.bat for ./gradlew.

16.2 Understand task outcome labels

Outcome	What it means
SUCCESS	Task executed successfully
FAILED	Task execution failed
UP-TO-DATE	Local outputs are considered current
FROM-CACHE	Gradle restored outputs from a cache
NO-SOURCE	Task had no relevant source inputs
SKIPPED	Task did not execute due to skip conditions

The task outcomes are particularly useful when deciding whether to optimize compilation, improve incremental execution, or enable caching.

16.3 Using the Develocity user interface

Most interactive investigation happens in the browser.

A practical exploration sequence is:

Open the Build Scan URL.
Read the build outcome and total duration.
Inspect the build timeline.
Open the task execution details.
Inspect test failures and logs.
Review relevant environment and dependency information.
Compare with another build when supported.
Share the Build Scan link with an authorized teammate.

For a private installation, the available navigation depends on permissions, license entitlements, and server version.

16.4 Commands for administrators

These operate on a Kubernetes installation rather than an individual development project.

kubectl --namespace develocity get pods
helm --namespace develocity list
helm --namespace develocity history ge
Code language: JavaScript (javascript)

Their purposes are:

get pods: inspect Kubernetes workloads.
helm list: display installed Helm releases.
helm history: inspect release revisions.

For deeper troubleshooting, you can inspect a selected pod:

kubectl --namespace develocity describe pod POD_NAME
kubectl --namespace develocity logs POD_NAME
Code language: PHP (php)

Replace POD_NAME with a real pod name obtained from kubectl get pods.

Be careful when sharing logs because they may contain operational or sensitive information.

16.5 A newer Gradle capability: Publish without changing the project

For Gradle 9.5.0 and later, the current documentation describes a command-line integration that can publish a Build Scan to a Develocity server without editing the project’s build scripts.

./gradlew assemble --develocity-url https://develocity.example.com
Code language: JavaScript (javascript)

The server URL must be replaced with a real authorized instance. Authentication may also be required.

This feature is version-specific; do not expect the same flag to work with older Gradle Wrappers.

Chapter 17. Configuration Explained

17.1 How Gradle configuration is organized

In a typical Gradle project, several configuration files play different roles. project/ ├── settings.gradle.kts ├── build.gradle.kts ├── gradle.properties ├── gradlew ├── gradlew.bat ├── gradle/ │ └── wrapper/ └── src/

File	Main purpose
settings.gradle.kts	Defines project structure and settings-level plugins
build.gradle.kts	Defines build tasks, dependencies, and plugins
gradle.properties	Supplies Gradle properties
gradlew / gradlew.bat	Runs the project-selected Gradle distribution
gradle/wrapper/	Contains wrapper configuration

The .kts extension means the file uses the Kotlin domain-specific language (DSL).

17.2 Configure a private Develocity server

For a Gradle 6-or-later project using the current plugin, a minimal configuration in settings.gradle.kts is:

plugins {
    id("com.gradle.develocity") version("4.6.1")
}

rootProject.name = "example-project"

develocity {
    server.set("https://develocity.example.com")

    buildScan {
        publishing.onlyIf { false }
        tag("TRAINING")
    }
}
Code language: JavaScript (javascript)

Explanation:

The plugins block applies the Develocity Gradle plugin.
server.set(…) points to the Develocity service.
publishing.onlyIf { false } disables automatic publication unless explicitly requested with –scan.
tag(“TRAINING”) adds a searchable label to published Build Scans.

The server URL is a placeholder. Use the actual hostname of a permitted Develocity instance.

The on-demand publication policy is useful when working with sensitive development projects.

17.3 Enable the Gradle Build Cache

Add this property to gradle.properties:

org.gradle.caching=true
Code language: JavaScript (javascript)

This enables Gradle task-output caching by default for eligible tasks.

You can still override it for a particular invocation with:

./gradlew build --no-build-cache

Enabling caching does not make every task cacheable. Gradle must know the relevant inputs and outputs, and the task must satisfy the requirements for safe reuse.

17.4 Configure a remote Develocity Build Cache

A typical private-server configuration looks like this:

buildCache {
    remote(develocity.buildCache) {
        server = "https://develocity.example.com"
        isPush = System.getenv("CI") == "true"
    }
}
Code language: JavaScript (javascript)

This configuration belongs in settings.gradle.kts, alongside the settings-level Develocity plugin configuration.

Here:

remote(…) selects a compatible Develocity remote cache.
server identifies the cache endpoint.
isPush controls whether this client is allowed to upload outputs.
System.getenv(“CI”) checks for a CI environment variable.

This is an example policy, not an appropriate default for every organization. It assumes your CI system sets CI=true, that remote-cache writes are authorized, and that the server supports this integration.

Many teams configure developer laptops to read cached outputs while restricting cache writes to trusted CI workflows.

Do not disable local caching merely because remote caching exists. The local cache frequently avoids network transfers.

17.5 Credentials and secrets

Private Develocity servers may require authentication.

One supported method is to provision a user-specific access key through Gradle:

./gradlew provisionDevelocityAccessKey

Depending on the configuration, this starts an interactive authentication flow and stores the key under the user’s Gradle home.

Another supported approach uses the environment variable DEVELOCITY_ACCESS_KEY, with a value containing the server hostname and key.

For CI environments, secrets should come from an approved secrets manager or CI secret store, not from committed project files.

Modern Develocity integrations also support short-lived access tokens. Where possible, short-lived, narrowly scoped credentials are preferable to persistent administrator credentials.

17.6 Maven integration

Maven projects use a different configuration mechanism.

A typical Maven project can load the Develocity extension through .mvn/extensions.xml.

<extensions xmlns="http://maven.apache.org/EXTENSIONS/1.1.0">
  <extension>
    <groupId>com.gradle</groupId>
    <artifactId>develocity-maven-extension</artifactId>
    <version>2.6.1</version>
  </extension>
</extensions>
Code language: HTML, XML (xml)

A separate .mvn/develocity.xml provides the server connection:

<develocity>
  <server>
    <url>https://develocity.example.com</url>
  </server>
</develocity>
Code language: HTML, XML (xml)

The XML above demonstrates the essential configuration, not a complete enterprise policy. Authentication, cache behavior, and publication rules may require additional settings.

After integration, run a normal Maven lifecycle command:

mvn verify

The extension observes the Maven build and can publish a Build Scan according to its configuration and server permissions.

17.7 Configuration precedence

There is no single universal precedence rule covering Gradle, Maven, Develocity server configuration, and environment variables.

For example, the Gradle plugin documents that an access key specified directly in the settings configuration takes precedence over one supplied through an environment variable or access-key file.

A team should document its chosen configuration sources and verify how command-line flags, settings files, user-level configuration, and CI environment variables interact for the specific integration.

17.8 Validate configuration

For Gradle:

./gradlew help --stacktrace

This verifies that Gradle can load project configuration and initialize the applied plugins.

Then run:

./gradlew build --scan

The first command can succeed even when publication cannot reach the server. The second provides an actual end-to-end publication test.

For Maven:

mvn -version
mvn verify

Check that the extension initializes, the build executes, and any expected Build Scan is published.

Chapter 18. Logs, Status, and Verification

18.1 Installation success is not operational success

Consider these four different states:

State	What you have proved
Java installed	Your machine can run Java
Gradle starts	The build tool can initialize
Build succeeds	The project builds successfully
Build Scan opens	Diagnostic publication and report access work

A complete verification should establish all relevant states.

18.2 Local development troubleshooting commands

java -version
./gradlew --version
./gradlew help --stacktrace
./gradlew build --info --scan

Use one command at a time and identify the first failed stage.

On Windows PowerShell, replace the Wrapper script with .\gradlew.bat.

18.3 How to inspect an individual Build Scan

A useful troubleshooting workflow is to start with the failed task or test, then review the related timeline and configuration information.

Avoid reading every detail from beginning to end. Use the failure to narrow the investigation.

For example, a compileJava failure usually calls for checking compilation diagnostics and source compatibility, not tuning remote-cache performance.

18.4 Check network connectivity

For an authorized private Develocity server, a basic HTTPS connectivity check is:

curl -I https://develocity.example.com/
Code language: JavaScript (javascript)

Replace the placeholder hostname.

The command requests HTTP response headers. A response, even an authentication-related response, may show that the host is reachable and serving HTTP.

A connection timeout, DNS failure, or TLS validation error indicates a different problem.

Do not use curl -k to make a broken certificate setup appear healthy. Fix the certificate trust problem.

18.5 Inspect Kubernetes workloads

For administrators:

kubectl --namespace develocity get pods
kubectl --namespace develocity get events
kubectl --namespace develocity get pvc
Code language: JavaScript (javascript)

These commands help answer:

Are the pods scheduled?
Are they running and ready?
Did image downloads fail?
Are persistent volumes bound?
Are Kubernetes events reporting resource or configuration problems?

When a specific pod is unhealthy:

kubectl --namespace develocity describe pod POD_NAME
kubectl --namespace develocity logs POD_NAME
Code language: PHP (php)

Replace POD_NAME with the actual pod.

If the container is restarting, inspect the previous container logs where supported:

kubectl --namespace develocity logs POD_NAME --previous
Code language: PHP (php)

18.6 What to monitor in production

Signal	Why it matters
Application health and readiness	Service availability
Build Scan publication failures	Missing diagnostic data
Cache availability	Build acceleration reliability
Cache hit rate	Cache effectiveness
Cache transfer time	Network overhead
Database health	Persistent data availability
Storage utilization	Capacity and retention risk
Authentication failures	Access and configuration problems
Pod restarts	Application or infrastructure instability
Build duration percentiles	Engineering performance trends

Cache hit rate is useful, but it is not sufficient by itself. A high hit rate on tiny tasks may save very little time, while a lower hit rate on expensive compilation tasks may yield substantial benefit.

18.7 A practical diagnosis sequence

NoYesNoYesNoYesNoYesProblem observedDoes the build start?Check Java, Wrapper and configurationDoes build work complete?Inspect failed task and logsBuild Scan published?Check publication policy, auth, DNS and TLSExpected cache reuse?Inspect task inputs, cacheability and cache accessMeasure performance and verify outcomes

Part V outcome: You can now configure a Gradle or Maven integration, understand the important command-line operations, inspect build results, and troubleshoot the major stages independently.

Part VI — Real-World Applications

Chapter 19. Practical Use Cases

The value of Develocity becomes clearer when it is connected to a specific engineering problem.

The following scenarios progress from individual development to large-scale enterprise operations.

Use case 1 — Find out why an Android build is slow

Problem: An Android developer experiences slow local builds after making relatively small code changes.

Environment: A multi-module Android project using the Android Gradle Plugin and Gradle.

Approach: Capture Build Scans for representative clean and incremental builds, then investigate task durations, configuration time, dependency resolution, and cache activity.

Android projectGradle buildBuild ScanTimeline analysisIdentify bottleneckChange build configurationMeasure again

A practical implementation would:

Establish a baseline using repeatable development tasks.
Record several executions rather than trusting a single timing.
Identify the consistently slow stages.
Determine whether the delays come from configuration, compilation, testing, resource processing, or external dependencies.
Change one relevant factor.
Compare the new results against the baseline.

Expected outcome: Better understanding of the build’s dominant costs and evidence for targeted optimization.

Success measures: Median local build time, p90 build time, configuration duration, and time from a small code change to usable feedback.

Risks: Comparing different source revisions or machine states can produce misleading conclusions. Android build behavior is influenced by many project-specific factors, and not every Gradle task is cacheable.

Use case 2 — Reduce repeated work in GitHub Actions

Problem: A team uses ephemeral CI runners. Every job begins in a fresh workspace, creating repeated compilation and test work.

Environment: GitHub Actions, Gradle, a shared cache, and an authorized private Develocity instance.

Approach: Configure eligible tasks to retrieve outputs from a shared Build Cache. Permit carefully controlled cache uploads from trusted CI workflows.

GitHub repositoryCI workflowRunner ARunner BShared Build CacheBuild and testPrivate Develocity

Implementation: Confirm that build tasks declare correct inputs and outputs, enable caching, configure cache authentication, and compare builds with and without shared cache access.

Expected outcome: Less repeated work on runners when equivalent cached outputs are available.

Success measures: CI duration percentiles, cache-hit time savings, cache-download duration, and total compute consumption.

Risks: Untrusted cache uploads, unstable task inputs, network bottlenecks, and accidental publication of sensitive build data.

Use case 3 — Investigate flaky tests across a large Java platform

Problem: A production engineering team encounters intermittent test failures.

Environment: Multiple Java services, Gradle or Maven, and a CI system that regularly executes automated test suites.

Approach: Use Build Scan and test analytics to identify recurring failures, execution patterns, and differences among environments.

A possible workflow is:

Collect test results consistently.
Find tests with inconsistent outcomes across comparable runs.
Identify likely sources such as timing, shared mutable state, environment dependencies, and test-order sensitivity.
Reproduce the failure in a controlled environment.
Fix the test or application behavior.
Continue tracking failure rates.

Expected outcome: More reliable test suites and less time lost to rerunning entire pipelines.

Success measures: Flaky-test rate, test failure investigation time, rerun frequency, and CI pass-rate stability.

Risks: A test that appears flaky may actually expose a real intermittent application defect. Automatically rerunning or ignoring it can hide a production issue.

Use case 4 — Standardize build diagnostics in a mixed Gradle and Maven organization

Problem: Teams use different Java build tools, making troubleshooting practices inconsistent.

Environment: Gradle projects, Maven projects, shared CI, and a central Develocity installation.

Approach: Integrate each build tool through its supported plugin or extension, then adopt common tags, ownership metadata, and troubleshooting procedures.

Implementation: Define a rollout standard covering integration versions, permitted scan content, access control, build identification, and cache policy. Test one Gradle and one Maven project before expanding.

Expected outcome: More consistent diagnostic information and clearer operational ownership.

Success measures: Percentage of supported builds publishing successfully, build-failure investigation time, and adoption across project teams.

Risks: Assuming feature parity between Gradle and Maven, incompatible extension versions, or creating excessive telemetry without a retention policy.

Use case 5 — Accelerate a geographically distributed engineering organization

Problem: Developers and CI workers operate in different regions, and accessing a distant cache can be slow.

Environment: Regional CI infrastructure, a private Develocity deployment, and Develocity Edge caching components.

Approach: Position supported cache infrastructure close to build clients while maintaining centrally managed build observability.

Implementation: Measure network latency, cache transfer times, cache hit rates, and actual build-duration improvement before deploying additional regional infrastructure.

Expected outcome: Reduced cache retrieval latency and more efficient build acceleration for compatible tasks.

Success measures: Time saved per cache hit, p90 build duration, regional cache availability, and network egress cost.

Risks: Cache topology complexity, regional outages, operating costs, and cache-integrity controls.

Use case 6 — Investigate container-image build performance

Problem: An engineering team spends significant time rebuilding container images.

Environment: Supported Docker BuildKit and Buildx versions with Develocity’s Docker integration enabled.

Approach: Use Docker Build Scans to investigate supported image-build behavior.

The Docker integration introduced with Develocity 2026.3 has its own prerequisites and does not imply that Gradle Build Cache settings apply to Docker layer caching.

Expected outcome: Better evidence about container-image build execution.

Success measures: Container-build duration, time spent in expensive build steps, and repeated work.

Risks: Different Docker builder implementations, integration version requirements, and differences between Docker’s caching model and language-build caching.

19.1 Choosing the right improvement

Observed problem	Investigate first	Possible intervention
Slow incremental builds	Re-executed tasks and configuration overhead	Improve incremental behavior and configuration caching
Slow clean builds	Expensive cacheable tasks	Build Cache
Long test execution	Test distribution and actual test durations	Test Distribution
Flaky CI	Failed-test patterns and environmental differences	Test reliability improvements
Slow dependency downloads	Repository latency and dependency resolution	Repository or artifact-cache optimization
Difficult troubleshooting	Missing execution context	Build Scan adoption
Remote cache is slow	Network and cache-transfer timings	Cache topology improvements

The key lesson is that the correct Develocity feature depends on the bottleneck.

Chapter 20. Complete Hands-On Project

Lab 2 · Beginner to intermediate · No commercial license required

20.1 Project objective

You will build a small Java calculator application from source, add automated tests, configure Develocity, experiment with Gradle Build Cache, analyze multiple Build Scans, introduce a deliberate defect, and verify its correction.

This lab combines:

Project configuration.
Java compilation.
Automated testing.
Develocity Gradle integration.
Build Scan publication.
Build Cache behavior.
Troubleshooting.
Repeatable performance measurement.

20.2 Architecture

Calculator.javaGradle projectCalculatorTest.javasettings.gradle.ktsbuild.gradle.ktsgradle.propertiesGradle WrapperCompile and testLocal Build CacheBuild resultDevelocity pluginPublic Build Scan serviceBrowser diagnostics

20.3 Requirements

Use the environment established in Chapter 14.

We will reuse the official quickstart’s Gradle Wrapper, avoiding the need to install Gradle globally.

Make sure you still have the gradle-build-scan-quickstart repository.

20.4 Create the project directory

From inside the quickstart repository, create the following structure:

gradle-build-scan-quickstart/
├── gradlew
├── gradlew.bat
├── gradle/
└── develocity-lab/
    ├── settings.gradle.kts
    ├── build.gradle.kts
    ├── gradle.properties
    └── src/
        ├── main/
        │   └── java/
        │       └── org/
        │           └── example/
        │               └── Calculator.java
        └── test/
            └── java/
                └── org/
                    └── example/
                        └── CalculatorTest.java

macOS/Linux:

mkdir -p develocity-lab/src/main/java/org/example
mkdir -p develocity-lab/src/test/java/org/example

Windows PowerShell:

New-Item -ItemType Directory -Force develocity-lab\src\main\java\org\example
New-Item -ItemType Directory -Force develocity-lab\src\test\java\org\example
Code language: PHP (php)

Open the develocity-lab directory in your code editor and create the following files.

20.5 Configure Develocity

File: develocity-lab/settings.gradle.kts

plugins {
    id("com.gradle.develocity") version("4.6.1")
}

rootProject.name = "develocity-lab"

develocity {
    buildScan {
        publishing.onlyIf { false }
        uploadInBackground.set(false)
        tag("SELF_STUDY")
    }
}
Code language: JavaScript (javascript)

Important details:

The plugin enables Build Scan integration.
publishing.onlyIf { false } makes publication opt-in via –scan.
uploadInBackground.set(false) makes publication complete before the command terminates, which is useful for this lab.
The tag helps identify your training builds.

We intentionally omit a private server URL so the free public service can be used.

20.6 Configure the Java build

File: develocity-lab/build.gradle.kts

plugins {
    java
}

repositories {
    mavenCentral()
}

dependencies {
    testImplementation("org.junit.jupiter:junit-jupiter:5.11.4")
    testRuntimeOnly(
        "org.junit.platform:junit-platform-launcher:1.11.4"
    )
}

tasks.test {
    useJUnitPlatform()
}
Code language: JavaScript (javascript)

The file does the following:

Enables Java compilation and testing.
Uses Maven Central for dependencies.
Adds JUnit Jupiter for automated tests.
Configures Gradle to run tests through the JUnit Platform.

JUnit is a testing framework for Java applications.

The specific JUnit versions are fixed here for reproducibility. In a real project, check the currently supported and security-approved versions before updating dependencies.

20.7 Enable build caching

File: develocity-lab/gradle.properties

org.gradle.caching=true
Code language: JavaScript (javascript)

This enables local Gradle Build Cache behavior for compatible tasks.

No remote cache server is required.

20.8 Write the application

File: develocity-lab/src/main/java/org/example/Calculator.java

package org.example;

public final class Calculator {

    private Calculator() {
    }

    public static int add(int a, int b) {
        return a + b;
    }

    public static int multiply(int a, int b) {
        return a * b;
    }
}
Code language: PHP (php)

This class implements two simple functions: addition and multiplication.

The constructor is private because we will use the class only through its static methods.

20.9 Write automated tests

File: develocity-lab/src/test/java/org/example/CalculatorTest.java

package org.example;

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertEquals;

class CalculatorTest {

    @Test
    void additionWorks() {
        assertEquals(5, Calculator.add(2, 3));
    }

    @Test
    void multiplicationWorks() {
        assertEquals(12, Calculator.multiply(3, 4));
    }

    @Test
    void additionHandlesNegativeNumbers() {
        assertEquals(-2, Calculator.add(-5, 3));
    }
}
Code language: JavaScript (javascript)

The @Test annotation tells JUnit that each method should be executed as an automated test.

assertEquals checks whether the actual output matches the expected value.

20.10 Run the first build

From the parent quickstart directory, not from inside develocity-lab, run:

macOS/Linux:

./gradlew -p develocity-lab clean test --build-cache --scan

Windows PowerShell:

.\gradlew.bat -p develocity-lab clean test --build-cache --scan
Code language: CSS (css)

The -p develocity-lab argument tells Gradle to use the nested directory as the project directory.

The clean task deletes generated outputs for that project.

The test task compiles the application and executes its tests.

The –build-cache argument enables caching for the run.

The –scan argument publishes a Build Scan after you accept the service terms.

Expected result: All three tests pass, the Gradle build succeeds, and a Build Scan URL appears.

20.11 Run the same clean build again

Run the same command a second time.

./gradlew -p develocity-lab clean test --build-cache --scan

Observe the task execution results.

For eligible tasks, you may see output similar to:

> Task :compileJava FROM-CACHE
> Task :test FROM-CACHE

BUILD SUCCESSFUL
Code language: CSS (css)

This is an illustrative expected pattern; the exact task outcomes depend on Gradle’s inputs, cacheability rules, and runtime conditions.

Why does it work?

The first execution generated outputs and stored eligible results. The clean task removed local build-directory outputs but did not clear the Gradle user-home cache.

On the second execution, Gradle can restore matching results from the cache.

20.12 Compare with an up-to-date build

Now run without clean:

./gradlew -p develocity-lab test --build-cache --scan

You may see:

> Task :compileJava UP-TO-DATE
> Task :test UP-TO-DATE

BUILD SUCCESSFUL
Code language: CSS (css)

This demonstrates the distinction:

UP-TO-DATE means local outputs remain valid.
FROM-CACHE means outputs were restored from a cache.

20.13 Introduce a deliberate application defect

Edit Calculator.java.

Change:

return a + b;
Code language: JavaScript (javascript)

to:

return a + b + 1;
Code language: JavaScript (javascript)

Keep the multiplication method unchanged.

Run:

./gradlew -p develocity-lab test --build-cache --scan

The addition tests should now fail.

This is a useful experiment because the code still compiles. The problem is behavioral rather than syntactic.

Inspect the new Build Scan and answer:

Which task failed?
Which tests failed?
What were the expected values?
What actual values did the code produce?
How does the failed Build Scan differ from the successful one?

20.14 Fix and verify

Restore the original addition method:

return a + b;
Code language: JavaScript (javascript)

Then run:

./gradlew -p develocity-lab clean test --build-cache --scan

Expected outcome: All tests pass.

Depending on available cache entries, task outcomes may be restored rather than executed again.

20.15 Compare three different executions

Create a small experiment record:

Experiment	Source state	Build command	Expected investigation
A	Correct	Clean test with cache	First build behavior
B	Correct	Repeat clean test with cache	Reuse of compatible cached outputs
C	Defective	Test with cache	Test failures and new execution behavior
D	Correct again	Clean test with cache	Recovery and potential cache reuse

Record the Build Scan URL and total duration for each run.

Do not assume that every performance difference comes from caching. Initial dependency downloads, JIT compilation, operating-system scheduling, and background processes can affect timing.

For meaningful performance experiments, compare several runs under similar conditions.

20.16 Troubleshooting the project

Problem	Likely cause	What to do
Plugin cannot be resolved	Network or repository issue	Verify Gradle Plugin Portal access
Java compilation fails	File path, package, or syntax mismatch	Check package org.example and Java syntax
Tests are not discovered	Test class or JUnit configuration error	Check @Test, dependencies, and source directory
Build Scan does not publish	Terms, network, or publication issue	Check console messages and service access
No FROM-CACHE result	Task inputs changed or cache entry unavailable	Compare inputs and rerun under identical conditions
‘-p project cannot be found	Incorrect working directory	Run from the quickstart parent directory
TLS or proxy failure	Corporate network restrictions	Use approved network and certificate configuration

20.17 Cleanup

You can keep the lab files for later exercises.

If you want to remove the project, close any tools that are using it and delete only the develocity-lab directory you created. Do not delete the entire quickstart repository unless you no longer need it.

The public Build Scans already uploaded are not removed by deleting local files. Review the public service’s privacy and retention controls if you need to manage published records.

20.18 Extend the project

Once the basic experiment works, consider:

Adding more tests and comparing execution durations.
Introducing additional Java source files.
Splitting the project into separate Gradle modules.
Adding custom Build Scan tags.
Enabling configuration caching after checking compatibility.
Running the project in an authorized CI environment.
Connecting a private Develocity instance with approved credentials.
Comparing cache behavior across two different machines.

Project success criterion: You can build and test a new Java project, publish Build Scans, explain UP-TO-DATE versus FROM-CACHE, diagnose an introduced defect, and verify that the corrected application works.

Part VII — Advanced Capabilities and Production Engineering

Chapter 21. Advanced Features

Once you understand Build Scans and caching, the next stage is using Develocity to optimize entire engineering workflows.

Not every advanced capability is included in every license, build integration, or deployment model. Confirm feature availability before designing around it.

21.1 Predictive Test Selection

Predictive Test Selection (PTS) attempts to identify tests that are most relevant to a particular code change.

Imagine a large application with 15,000 automated tests. Running all of them after every small change may create substantial delays.

PTS helps prioritize a subset of tests based on available information about the changes and the test suite.

NoYesCode changeChange and test informationPredictive Test SelectionSelected testsFast feedbackTests pass?Investigate failureContinue delivery workflowFull suite at defined checkpoints

Why it matters: Faster feedback can reduce waiting during code review and development.

Important limitation: Selected tests do not provide the same coverage as executing every test. Keep appropriate full-suite testing at defined checkpoints, particularly for safety-critical, security-sensitive, and release-critical changes.

PTS should supplement a broader testing strategy rather than become a justification for permanently skipping important tests.

21.2 Test Distribution

Test Distribution allows suitable test workloads to be executed across multiple agents.

Without distribution:

Test suiteOne test workerAll tests completed

With distribution:

Test suiteTest coordinatorAgent AAgent BAgent CCollect resultsCombined test outcome

The benefit depends on whether tests can execute independently, how expensive they are, and how much coordination overhead is involved.

Adding more agents does not guarantee proportional speed improvement.

For example, shared database contention could prevent independent execution, and environment provisioning may consume much of the time saved.

Prerequisites: A supported build/test integration, suitable agents, network connectivity, compatible test environments, and the relevant Develocity feature entitlement.

21.3 Develocity Edge

Develocity Edge is designed to improve distributed caching and related artifact-serving workflows.

A common enterprise problem is geographic distance between CI workers and centralized services.

Suppose a CI runner in Asia repeatedly retrieves large outputs from a service located in another region.

Even when the outputs are cached, network latency and transfer costs can reduce the benefit.

Edge deployments can bring caching capabilities closer to the clients that consume them.

For new infrastructure designs, prefer the supported Edge architecture rather than the legacy standalone Build Cache node model. Official documentation states that standalone Build Cache node support ends with the transition to Develocity 2027.1.

21.4 Artifact Cache and Setup Cache

Although they all involve reuse, the acceleration technologies address different stages of work.

Technology	What is reused	Example
Build Cache	Outputs of compatible build tasks	Compiled Java classes
Artifact Cache	Supported dependency or artifact downloads	Previously retrieved package content
Setup Cache	Eligible environment setup information	Reusable build setup state
Configuration Cache	Gradle build-configuration state	Avoid repeated configuration work

Do not assume a Build Cache will automatically eliminate all package downloads or repeated machine initialization.

Choose the mechanism that corresponds to the actual work being repeated.

21.5 Build Caching Optimizer

A build may have low cache reuse because tasks are not cacheable, relevant inputs change unnecessarily, or configuration introduces variability.

Develocity’s build-caching analysis capabilities can help identify such problems.

A sensible process is:

Select a frequently executed build.
Capture several representative executions.
Identify expensive work that appears repeatedly.
Determine whether the work is eligible for caching.
Examine task input changes and missed reuse opportunities.
Correct task configuration where necessary.
Measure performance and validate output correctness.

Avoid optimizing only the cache-hit percentage. The more meaningful question is how much useful time and compute have been saved.

21.6 APIs and AI-assisted investigation

Develocity provides APIs and MCP-related capabilities for accessing supported build information programmatically.

Possible enterprise applications include:

Creating engineering productivity dashboards.
Identifying recurrent CI failures.
Comparing historical build patterns.
Answering questions about slow builds.
Incorporating build diagnostics into authorized AI workflows.

For example, an engineering assistant might help answer: Which Gradle tasks explain the increase in build duration for our main CI workflow?

A safe implementation would grant that assistant narrowly scoped read access to relevant build data, rather than broad administrative permissions.

API integrations must validate authorization, avoid unnecessarily exposing logs or environment information, and treat build output as potentially sensitive data.

21.7 Automation patterns

Advanced teams often automate repetitive diagnostic activities.

Automation	Trigger	Action
Build-regression report	Daily or weekly schedule	Compare build-duration trends
Cache-efficiency review	Cache time savings declines	Investigate reuse patterns
Flaky-test review	Repeated inconsistent test failures	Create an investigation work item
Platform health monitoring	Service degradation	Notify platform operations
Integration compatibility review	Version changes	Test plugins before upgrading
Capacity review	Sustained storage or workload growth	Review retention and resources

Automation should notify teams about actionable problems rather than generate large quantities of low-value alerts.

21.8 Advanced learning objective

By the end of this chapter, you should be able to distinguish between reducing repeated computation, reducing test execution, distributing work, and improving diagnostics.

These are different optimization strategies, and a mature engineering team chooses among them based on evidence.

Chapter 22. Security Best Practices

A Develocity installation may receive detailed information about source-code builds, dependencies, environments, test failures, and CI infrastructure.

That makes security and data governance important from the beginning.

22.1 Main security responsibilities

The most important concerns are:

Who can publish a Build Scan?
Who can view the resulting data?
What information is captured?
Which builds may upload cache entries?
Can untrusted code influence outputs consumed by trusted builds?
How are access keys and tokens protected?
How is data retained and deleted?
How are server components updated?

22.2 Insecure practices versus safer alternatives

Insecure practice	Risk	Safer alternative
Publishing confidential projects to a public service	Data disclosure	Use an authorized private instance
Committing access keys to Git	Credential exposure	Use CI secret stores or scoped credentials
Disabling TLS certificate validation	Interception risk	Use trusted certificates
Allowing all pull-request builds to write trusted cache entries	Cache poisoning	Separate trusted and untrusted writes
Using administrator credentials for every integration	Excessive permissions	Least-privilege accounts and tokens
Giving all users unrestricted scan access	Information exposure	SSO and project-level access control
Retaining all telemetry indefinitely	Growing security and storage exposure	Defined retention policy
Running outdated server versions	Known defects or vulnerabilities	Controlled patch management
Treating cache hits as proof of correctness	Incorrect output reuse	Properly declared inputs and validation
Sending full Build Scan content into unrestricted AI systems	Data leakage	Permissioned and audited integrations

22.3 Protecting Build Scan information

A Build Scan can include information that developers do not normally intend to publish publicly.

Potential examples include repository names, dependency coordinates, environment details, build arguments, captured console output, and test failure messages.

The precise information captured depends on the integration and configuration.

Before enabling publication for a company project, security and engineering teams should review the data captured, applicable redaction and obfuscation controls, server access policies, and organizational data-handling requirements.

22.4 Credential management

Access keys should be treated as secrets.

For CI environments, prefer:

Approved secret storage.
Credentials restricted to the required server.
Minimum required permissions.
Short validity periods where supported.
Credential rotation and revocation procedures.
Separate identities for different CI trust levels.

Never paste a real access key into a publicly shared troubleshooting log or Build Scan.

22.5 Build Cache trust boundaries

One of the most important security topics is cache poisoning.

Imagine that an untrusted build can upload an output that another trusted build later reuses.

If cache isolation and task identity protections are inadequate, this could affect the integrity of trusted build results.

Develocity 2026.3 introduced trusted-artifact isolation capabilities involving workload identity. These require proper configuration; they are not a substitute for trustworthy build logic and appropriate CI permissions.

A useful trust model is:

Untrusted pull requestRestricted CI identityProtected main branchTrusted CI identityUntrusted cache scopeTrusted cache scopeControlled reuse policyRelease-critical build

The dotted path represents a decision that must be governed by an explicit trust policy, not unconditional cache sharing.

22.6 Secure deployment checklist

Enterprise security assessment

[ ] TLS certificates are valid and trusted
[ ] SSO and least-privilege access are configured
[ ] Build Scan data classification has been reviewed
[ ] Credentials are stored outside source control
[ ] Cache write permissions follow CI trust boundaries
[ ] Server and integration versions are approved
[ ] Audit logging and operational monitoring are enabled
[ ] Backups and restore procedures are tested
[ ] Retention and deletion policies are documented
[ ] AI and API integrations use restricted permissions

These are learning checks, not a formal certification or proof that a deployment is secure.

Chapter 23. Production-Ready Architecture

The transition from a local lab to a production service requires much more than installing a Helm chart.

23.1 Reference production architecture

Managed Kubernetes clusterEngineering and CI environmentsDeveloper workstationsTrusted CI runnersRestricted CI runnersHTTPS ingress / load balancerDevelocity application servicesCaching services and EdgeMonitoring and alertingManaged PostgreSQLPersistent object storageEnterprise identity providerSecrets managerBackup and recovery system

This is a logical reference architecture, not an exact Helm resource diagram. Specific components and storage connections must follow the supported deployment model.

23.2 Essential, recommended, and optional components

Component	Classification	Why
Supported Kubernetes infrastructure	Essential for self-hosted installation	Runs the application
Valid Develocity license	Essential	Authorizes the installation
Trusted HTTPS endpoint	Essential for secure operation	Protects communication
Database and required persistent storage	Essential	Maintains state
Supported backup mechanism	Essential for production resilience	Enables recovery
Health monitoring	Essential	Detects service failures
SSO integration	Strongly recommended	Centralizes identity management
Managed PostgreSQL	Deployment-dependent recommendation	Can simplify database operations
Object storage	Required where specified by the chosen architecture	Stores supported durable data
Regional Edge deployment	Optional	Improves applicable distributed workloads
Reporting integrations	Optional	Enables custom analytics
Dedicated performance testing	Recommended	Validates scaling decisions

23.3 Capacity planning

Begin with the official deployment requirements, then estimate workloads.

Important variables include:

Number of active build clients.
Builds per day.
Average Build Scan size.
Cache upload and download volume.
Number and size of projects.
Test-result volume.
Telemetry retention requirements.
Geographic distribution.
Expected growth.
Availability requirements.

Consider an illustrative storage-planning exercise.

If an organization generates 20,000 Build Scans per day and retains them for 30 days: [ 20{,}000\times30=600{,}000\text{ Build Scans} ]

That gives a record count, not a disk-space estimate. Actual storage depends on scan contents, compression, indexes, application overhead, and retention behavior.

Measure representative data rather than inventing a fixed number of megabytes per scan.

23.4 Reliability and recovery objectives

Two operational concepts are important.

Recovery Time Objective (RTO): The maximum acceptable time to restore service after a significant failure.

Recovery Point Objective (RPO): The maximum acceptable amount of data loss measured in time.

For example, a company could choose an RTO of four hours and an RPO of one hour. These are illustrative business decisions, not Develocity default guarantees.

The architecture and backup schedule must be designed to meet the organization’s actual objectives.

23.5 Monitoring and alerting

Monitor the service at three layers.

Layer	Example signals	Responsible team
Infrastructure	CPU, memory, disk, network, pod readiness	Platform/SRE
Develocity service	Application health, ingestion and cache errors, authentication failures	Platform/DevEx
Engineering outcomes	Build duration, cache savings, flaky-test trends	Build engineering

An alert should ideally identify the affected service, impact, recommended investigation, and owning team.

23.6 Upgrade and rollback strategy

Production upgrades require a controlled process.

Review Develocity release notes and compatibility requirements.
Check Kubernetes, Helm, database, and storage dependencies.
Identify deprecated integrations and deployment components.
Test the upgrade against a representative non-production environment.
Confirm that verified backups exist.
Schedule the production change.
Upgrade using the vendor-supported procedure.
Verify application health, publication, authentication, and cache access.
Monitor for regressions.
Execute the documented recovery procedure if necessary.

Helm provides revision history:

helm --namespace develocity history ge
Code language: PHP (php)

Helm also supports rollback commands, but a Helm rollback is not automatically a safe database or application-data rollback. Before using it, verify the vendor’s downgrade compatibility and recovery instructions. Schema migrations and persistent state may not be reversible simply by changing the chart revision.

23.7 Production readiness checklist

Before announcing the service as ready, confirm:

[ ] Deployment architecture is supported.
[ ] Licensing and capacity are sufficient.
[ ] DNS, TLS, ingress, and firewall policies are tested.
[ ] Authentication and authorization work.
[ ] Build Scan publication succeeds from development and CI.
[ ] Cache reads and authorized writes work.
[ ] Data retention is configured.
[ ] Backups have been restored successfully in a test environment.
[ ] Alerts reach the responsible team.
[ ] Upgrade and incident-response runbooks exist.
[ ] Cost and usage monitoring is in place.
[ ] Legacy components and compatibility risks are documented.

A production deployment is ready only when the team can operate and recover it—not merely when every Kubernetes pod reports Running.

Part VIII — Troubleshooting and Mastery

Chapter 24. Common Problems and Solutions

24.1 Troubleshooting reference

Problem or error	Likely cause	How to diagnose	Solution	How to verify
java: command not found	JDK missing or PATH incorrect	Run java -version	Install supported JDK and update PATH	Java version displays
Invalid JAVA_HOME	Wrong JDK path	Inspect environment	Point to JDK root	Gradle starts
Gradle Wrapper download fails	Proxy, DNS, TLS, or network	Inspect error and download URL	Configure approved network settings	gradlew –version succeeds
Plugin cannot be resolved	Repository or compatibility problem	Run with –stacktrace	Check plugin version and repository access	Gradle configures
Java compilation fails	Source or compiler mismatch	Read compiler errors	Fix source or toolchain	Compile task passes
JUnit tests are not discovered	Dependency or configuration issue	Inspect test setup	Correct JUnit and test task configuration	Tests execute
Build Scan URL missing	Publication disabled or failed	Check policy and logs	Enable permitted publication; fix connectivity	Scan URL appears
Build Scan returns access denied	Authentication or authorization issue	Check account and permissions	Use authorized identity	Report opens
TLS handshake fails	Certificate trust or server mismatch	Check certificate chain	Fix trusted certificate configuration	HTTPS works
Remote cache has no hits	Inputs differ or cache not populated	Inspect task inputs and caching details	Correct cacheability or policy	Eligible output restored
Remote cache is slower	Network overhead or poor locality	Measure transfer time	Review cache topology	Build time improves
CI ends before scan upload finishes	Background upload terminated	Inspect publication behavior	Disable background upload for ephemeral CI	Scan reliably appears
Pod remains pending	Insufficient capacity or scheduling issue	kubectl describe pod	Correct resources or scheduling	Pod becomes ready
Persistent volume unbound	Storage provisioning issue	kubectl get pvc	Fix supported storage configuration	PVC becomes bound
Develocity server unavailable	Service, ingress, DNS, or dependency problem	Inspect health and logs	Repair failed component	Health and access recover
Login fails	Identity provider or access-control problem	Review auth configuration and logs	Correct federation or permissions	Authorized login succeeds

The problem descriptions are typical troubleshooting categories. Except for standard command and runtime diagnostics, they should not be interpreted as exact verified Develocity error messages.

24.2 Troubleshooting Build Scan publication

Suppose a build completes successfully but no Build Scan appears.

Investigate in this order:

Was the Develocity integration applied?
Does the project’s publication policy allow this build?
Was –scan supplied when the policy is on-demand?
Did the user agree to the public-service terms where applicable?
Does the computer have network access to the configured service?
Is HTTPS certificate validation successful?
Does the user or CI identity have permission to publish?
Was the build terminated before an asynchronous upload completed?

The Gradle plugin documentation describes a background-upload failure log at: ~/.gradle/build-scan-data/upload-failure.log

Inspect it when an upload fails silently after the build finishes. The file might not exist if no such failures occurred.

24.3 Troubleshooting Build Cache

A missing cache hit does not automatically indicate an error.

Consider these possibilities:

The task is not cacheable.
The task has never executed with the same relevant inputs.
A compiler or build-plugin version changed.
A declared input changed.
The cache entry has been evicted.
Cache access or permissions are incorrect.
Local or remote caching is disabled.
The task was skipped through up-to-date checking before a cache lookup was necessary.

A practical diagnostic experiment is to run a stable project twice, deliberately cleaning only generated build outputs between runs.

./gradlew clean build --build-cache --scan
./gradlew clean build --build-cache --scan

Then inspect whether eligible tasks were restored and why other tasks executed.

24.4 Troubleshooting systematic performance regressions

Use a structured process.

Step 1: Identify the affected workflow: local, CI, clean, incremental, or test-only.

Step 2: Select comparable successful builds from before and after the regression.

Step 3: Compare total duration and key stages.

Step 4: Examine task execution changes, dependency resolution, cache behavior, and resource conditions.

Step 5: Form a specific hypothesis.

Step 6: Test one change.

Step 7: Measure multiple representative runs.

Step 8: Retain or reverse the change based on evidence.

Do not simultaneously change hardware, Gradle versions, compiler settings, cache policy, and test parallelism during a performance experiment. That makes it difficult to identify which modification caused the result.

24.5 Commands requiring caution

Command or action	Potential impact
./gradlew clean	Deletes generated outputs of the selected Gradle project
git restore FILE	Discards uncommitted changes in that file
kubectl delete …	Can remove Kubernetes resources and interrupt service
helm uninstall …	Removes a Helm release and may disrupt workloads
helm rollback …	Changes deployed resources; does not guarantee data rollback
Clearing a shared cache	Causes expensive cache repopulation
Changing firewall rules	May interrupt CI or user connectivity
Changing cache permissions	Can alter security and build behavior

Production changes require authorization, impact analysis, and a recovery plan.

Chapter 25. Best Practices and Common Mistakes

25.1 Universal engineering practices

These are good habits regardless of which tool you use.

Measure before optimizing. Avoid fixing a bottleneck that has not been demonstrated.

Make experiments repeatable. Record the source revision, command, Java version, relevant hardware, cache configuration, and environment.

Compare similar workloads. A large clean build should not be compared directly with a small incremental build as though they measured the same thing.

Prefer controlled changes. Change one important factor at a time.

Document configuration. Engineers should know how scans are published, where the cache lives, and who can write to it.

Validate correctness. Faster incorrect builds have no value.

Observe long-term trends. One exceptionally fast execution is less useful than sustained improvement across normal workloads.

25.2 Develocity-specific practices

Recommended practice	Why it matters
Adopt Build Scans before widespread caching changes	Establishes visibility and a baseline
Use clear build tags	Makes analysis and search easier
Separate local and CI measurement	Workloads behave differently
Keep Build Scan publication policies explicit	Prevents unintended data sharing
Protect cache write permissions	Preserves build integrity
Keep integration versions managed	Reduces compatibility surprises
Track time saved, not only hit counts	Measures actual value
Test cache correctness	Prevents reuse of incorrect outputs
Monitor scan publication reliability	Avoids gaps in diagnostic history
Review storage and retention	Controls operational costs

25.3 Common mistakes

Mistake 1: Enabling caching without understanding task inputs. The result may be disappointing performance or, in poorly implemented tasks, incorrect reuse.

Mistake 2: Treating every slow build as a cache problem. Some delays come from network access, tests, configuration, or machine resource contention.

Mistake 3: Using Build Scan as a replacement for application monitoring. Build diagnostics and runtime monitoring address different systems.

Mistake 4: Assuming selected tests equal complete regression coverage. Test selection is an acceleration technique, not proof that all unselected behavior is correct.

Mistake 5: Enabling remote cache writes for untrusted workflows. Cache trust boundaries are part of software supply-chain security.

Mistake 6: Comparing only successful builds. Failed builds often expose the most important reliability problems.

Mistake 7: Measuring a single build. Build duration can be affected by background activity, downloads, daemon warmup, and resource scheduling.

Mistake 8: Deploying production infrastructure without a restore test. A backup is useful only if the team can recover the service from it.

25.4 A continuous improvement operating model

Collect build dataMeasure trendsPrioritize bottleneckImplement improvementValidate correctnessMeasure business impactDocument and standardize

A mature team repeats this process and adjusts its priorities as build behavior changes.

Chapter 26. Learning Roadmap

The following is a suggested progression, not an official certification syllabus.

Stage	Suggested effort	Topics	Practical activity	Expected skill
1. Fundamentals	3–5 hours	Build tools, CI, caching, terminology	Explain a build workflow	Conceptual understanding
2. First use	2–4 hours	JDK, Gradle Wrapper, Build Scan	Complete Lab 1	Independent basic use
3. Practical use	5–8 hours	Tasks, cache behavior, diagnostics	Complete Lab 2	Working proficiency
4. Team integration	6–10 hours	CI, publication policies, remote cache	Integrate an approved project	Team-level competence
5. Advanced optimization	8–12 hours	Test optimization, caching analysis, APIs	Investigate a real bottleneck	Applied competence
6. Production operations	10–16 hours	Kubernetes, security, storage, observability	Design and review deployment	Operational readiness

26.1 Recommended study order

Understand how software builds work.Learn task graphs, dependencies, testing, and caching.
Use Gradle and Build Scan.Run the official quickstart and investigate build results.
Master local cache behavior.Compare clean, incremental, up-to-date, and cached executions.
Improve a real CI workflow.Establish a baseline and test a small change.
Study advanced acceleration and test optimization.Learn when remote caching, test distribution, and PTS are suitable.
Learn enterprise operation.Cover identity, Kubernetes, backups, monitoring, upgrades, and incident response.

26.2 Official documentation and learning resources

The following are the most important resources to bookmark.

Resource	Why to use it
Develocity documentation	Platform releases, installation, integrations, and administration
Develocity Gradle plugin manual	Gradle integration and configuration
Official Build Scan quickstart	Free hands-on sample
Gradle User Manual	Build tool concepts and operation
Gradle Build Cache	Cache inputs, outputs, and configuration
DPE University	Structured developer productivity learning
Develocity product website	Product overview and commercial options

The documentation URLs link to current or explicitly identified documentation families. Recheck the version-specific guides when upgrading.

26.3 Skills to demonstrate before production work

A practitioner should be able to:

Explain why a task executed.
Distinguish cached output reuse from up-to-date checking.
Capture and investigate a failed Build Scan.
Safely configure Build Scan publication.
Analyze CI performance using several representative runs.
Explain which workflows may write to a shared cache.
Verify that a caching optimization preserves build correctness.
Diagnose publication failures independently of build failures.
Design a monitoring and backup plan for a private installation.

Chapter 27. Exercises and Knowledge Assessment

Complete these questions before reading the answer key.

27.1 Beginner assessment

Question 1 — Multiple choice

What is the primary purpose of Develocity?

A. Replace Git repositories.
B. Observe, troubleshoot, and accelerate supported builds and tests.
C. Compile Java without a build tool.
D. Monitor production website visitors.

Question 2 — Multiple choice

Which component actually executes a normal Gradle project build?

A. Gradle.
B. The Develocity web interface.
C. PostgreSQL.
D. Kubernetes.

Question 3 — Multiple choice

What does FROM-CACHE normally indicate?

A. A task failed.
B. A task has no inputs.
C. Compatible outputs were restored from a build cache.
D. The application was deployed.

Question 4 — Short answer

Explain the difference between a Build Scan and a Build Cache.

Question 5 — Short answer

Why is it important to understand a software build process before learning Develocity?

27.2 Intermediate assessment

Question 6 — Multiple choice

A developer runs ./gradlew build twice without changing anything. Many tasks show UP-TO-DATE.

What does that mean?

A. The tasks were necessarily restored from a remote cache.
B. Gradle determined that current local outputs were valid.
C. Develocity skipped the build.
D. The project had no source code.

Question 7 — Multiple choice

Which command requests a Build Scan for the sample Gradle project?

A. ./gradlew build –scan
B. ./gradlew deploy –develocity-install
C. ./gradlew build –enable-ssh
D. ./gradlew scan-only –database

Question 8 — Practical exercise

Run the custom calculator project from Chapter 20 with Build Cache enabled. Execute a clean build twice.

Identify which tasks executed and which were restored from cache.

Question 9 — Practical exercise

Change the addition method so it produces an incorrect result. Capture a Build Scan for the failing tests.

Identify the failed task and test methods, then restore the correct implementation.

Question 10 — Short answer

A CI build succeeds, but no Build Scan URL is produced.

Name four things you would check.

27.3 Advanced assessment

Question 11 — Scenario

Your organization has 200 engineers using ephemeral CI runners. Compilation is expensive and repeated frequently.

Which Develocity capability would you investigate first, and why?

Question 12 — Scenario

Your organization has a 90-minute test suite. Most changes affect only a small portion of the application.

Compare Predictive Test Selection and Test Distribution. Explain how they address the problem differently.

Question 13 — Scenario

A remote cache has a high cache-hit rate, yet build performance barely improves.

What should you measure before modifying the infrastructure?

Question 14 — Security scenario

An external contributor opens an untrusted pull request. The CI system can upload to the same trusted cache used by release builds.

What is the risk, and how would you reduce it?

Question 15 — Architecture scenario

A company wants to deploy Develocity on Kubernetes.

List five production requirements beyond simply creating the application pods.

Question 16 — Practical architecture exercise

Draw a Mermaid diagram with:

Developer laptops.
CI runners.
Private Develocity service.
Shared caching infrastructure.
Persistent database.
Enterprise identity provider.

Label which connections are associated with telemetry and which with cached outputs.

Question 17 — Operational scenario

An upgrade changes database state and the new application release fails. Why might a simple Helm rollback be insufficient?

Question 18 — Decision exercise

A team has a small Java project with reliable 15-second builds.

Would you recommend immediately deploying a private Develocity server? Explain.

27.4 Answer key and explanations

Question 1. B — Develocity observes, analyzes, and accelerates supported build and test workflows. It does not replace the build tool.

Question 2. A — Gradle executes the tasks. Develocity provides integrated observability and acceleration.

Question 3. C — Gradle restored eligible task outputs from a cache rather than performing the same work again.

Question 4. A Build Scan contains diagnostic information about one build execution. A Build Cache stores reusable outputs of compatible tasks.

Question 5. Understanding tasks, dependencies, compilation, and tests lets you interpret diagnostics and select appropriate optimizations rather than treating Develocity as a black box.

Question 6. B — UP-TO-DATE means Gradle determined that local task outputs were valid for the relevant inputs.

Question 7. A — ./gradlew build --scan requests publication of a Build Scan, subject to configuration and publishing conditions.

Question 8. Run the same clean build twice and compare the scans. Eligible tasks may show FROM-CACHE on the second execution; record actual outcomes instead of assuming every task is cacheable.

Question 9. Changing a + b to a + b + 1 should fail the addition assertions. Inspect the test task and report, restore the method, and confirm that tests pass.

Question 10. Check whether the plugin is applied, whether publishing is enabled, whether the server is reachable, and whether authentication works. Also check TLS, public-service terms, and background-upload behavior.

Question 11. Investigate shared Build Cache because compatible compilation outputs may be reused across ephemeral runners. First establish task cacheability and baseline performance.

Question 12. Predictive Test Selection chooses a subset of relevant tests. Test Distribution runs suitable tests in parallel across agents. They address different costs and may be combined where supported.

Question 13. Measure absolute time saved, transfer size and duration, task cost, whether hits affect expensive tasks, and network latency. Hit rate alone is insufficient.

Question 14. Untrusted cache uploads may compromise the integrity of outputs consumed by trusted builds. Apply separated cache trust scopes, limited write permissions, and identity controls.

Question 15. Important requirements include licensing, HTTPS, persistent databases and storage, authentication, monitoring, backups, tested restores, resource capacity, and documented upgrades.

Question 16. A good diagram separates telemetry publication, cache reads and writes, persistent storage, and identity-provider communication, and marks the private trust boundary.

Question 17. Helm rollback may not undo schema migrations or other changes to persistent state. Recovery may require a vendor-supported downgrade or restoring compatible backups.

Question 18. Probably not immediately. Use built-in Gradle diagnostics and the free tools first, then evaluate a commercial platform when a measurable need emerges.

27.5 Final practical assessment

To demonstrate working competence, complete a small independent project where you:

Build and test a Gradle project.
Publish a Build Scan.
Investigate one real or deliberately introduced failure.
Demonstrate local cache reuse.
Measure an optimization using more than one build.
Explain the security implications of publishing telemetry and sharing cache outputs.

Passing this assessment is stronger evidence of skill than merely memorizing the command reference.

Chapter 28. Final Revision and Quick Reference

28.1 Develocity in one paragraph

Develocity is a platform for observing, troubleshooting, and accelerating software builds and tests. It works with supported build tools and integrates with development and CI environments. Its key capabilities include Build Scans, shared caching, historical performance analysis, test diagnostics, and advanced acceleration features. It helps engineers make evidence-based improvements, but it does not replace the underlying build systems or eliminate the need for secure configurations and reliable tests.

28.2 The five most important concepts

Build execution: The build tool performs compilation, testing, and packaging.
Build Scan: Diagnostic information explains what happened during a build.
Build Cache: Compatible task outputs can be reused to avoid repeated work.
Build and test optimization: Different bottlenecks require different acceleration strategies.
Operational governance: Correctness, security, observability, and recovery remain essential at scale.

28.3 One-page Develocity cheat sheet

Develocity Quick Reference

Keep this page for daily development and troubleshooting.

Core terminology

Term	Remember
Build Scan	What happened?
Build Cache	Can existing outputs be reused?
UP-TO-DATE	Local outputs are still valid
FROM-CACHE	Outputs were restored
Test Distribution	Execute suitable tests across agents
PTS	Select relevant tests
Edge	Distributed cache infrastructure

Essential Gradle commands — macOS/Linux

<em># Verify Gradle</em>
./gradlew --version

<em># Build with a Build Scan</em>
./gradlew build --scan

<em># Run tests</em>
./gradlew test --scan

<em># Investigate an error</em>
./gradlew build --stacktrace

<em># Experiment with caching</em>
./gradlew clean build --build-cache --scan

<em># Disable cache for comparison</em>
./gradlew build --no-build-cache
Code language: HTML, XML (xml)

On Windows, use .\gradlew.bat in place of ./gradlew.

Gradle configuration essentials

plugins {
    id("com.gradle.develocity") version("4.6.1")
}

develocity {
    buildScan {
        publishing.onlyIf { false }
    }
}
Code language: JavaScript (javascript)

Place this in settings.gradle.kts. For a private instance, configure its server URL and approved authentication separately.

Enable local caching

org.gradle.caching=true
Code language: JavaScript (javascript)

When a build is slow

Open its Build Scan.
Find the expensive stages.
Check task and cache behavior.
Form a specific hypothesis.
Make one change and measure again.

When a Build Scan is missing

Check the integration, publication policy, network, TLS, authentication, and upload behavior.

When cache reuse is missing

Check task cacheability, changed inputs, available entries, permissions, and cache availability.

Security essentials

Never commit tokens, expose confidential scans publicly, disable TLS validation as a permanent workaround, or permit untrusted builds to write trusted cache content without appropriate isolation.

Best first project

Use the official Build Scan quickstart, then complete the calculator project in Chapter 20.

28.4 When Develocity is most useful

Develocity is particularly valuable when engineering teams face repeated build performance regressions, slow CI pipelines, expensive compilation and tests, flaky test behavior, difficult cross-environment debugging, or the need for centralized productivity analysis.

A private installation becomes more compelling as the number of teams, build executions, CI environments, and operational requirements increases.

28.5 When another approach may be better

For small projects, native Gradle or Maven diagnostics may be entirely adequate.

For monorepos built primarily with Bazel or Nx, evaluate the corresponding ecosystem-specific acceleration platforms as well.

For software quality analysis, security scanning, and application runtime monitoring, use tools designed for those purposes rather than treating Develocity as a substitute.

Final course outcome

You have completed the learning path from software-build fundamentals to Develocity’s architecture, integrations, installation, configuration, daily usage, advanced acceleration, security, production deployment, and troubleshooting.

The most important practical progression is:

First: Run the official Build Scan quickstart from Chapter 15.
Second: Complete the Java calculator and Build Cache experiments in Chapter 20.
Third: Apply the same diagnostic method to an authorized real development or CI workload.
Finally: Evaluate commercial Develocity deployment and advanced acceleration only when measurements justify them.

The central principle of Developer Productivity Engineering is simple: measure the actual problem, understand its cause, change the appropriate part of the system, verify correctness, and measure the result. Develocity is useful because it provides evidence and capabilities that help engineers repeat that process at scale.

Documentation and version-sensitive product details verified against official sources as of October 28, 2026. Lab execution results are described as expected outcomes; commands were not executed against the reader’s machine or a licensed Develocity environment.

Official references

The examples include version-sensitive details. Check official documentation before applying them to a production system.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.

Find Trusted Cardiac Hospitals

Compare heart hospitals by city and services — all in one place.

Explore Hospitals

Find the Best Cosmetic Hospitals

About this course

Part I — Understand the World Before the Tool

Chapter 1. The Big Picture

1.1 The problem: Why does software take so long to build?

1.2 A relatable analogy

1.3 What happens in a typical software development environment?

1.4 Why traditional solutions are insufficient

1.5 Where Develocity fits

What You Should Understand Before Moving On

Chapter 2. Prerequisite Concepts

2.1 What is a build tool?

2.2 What is a software dependency?

2.3 What is caching?

2.4 Four concepts beginners commonly confuse

2.5 Why is observability important?

Chapter 3. Essential Terminology and Glossary

Chapter 4. How Software Builds Work Without Develocity

4.1 A traditional development workflow

4.2 What makes builds slow?

4.3 Why faster hardware is not always the answer

4.4 The measurement principle

Part II — Understand Develocity

Chapter 5. What Is Develocity?

5.1 The simplest definition

5.2 Beginner-friendly explanation

5.3 Technical definition

5.4 Is Develocity the same as Gradle?

5.5 Where does Develocity run?

5.6 What Develocity does not replace

Chapter 6. Why Does Develocity Exist?

6.1 The cost of slow feedback

6.2 Three realistic scenarios

6.3 What benefits are realistic?

6.4 Trade-offs

6.5 When Develocity is unnecessary

Chapter 7. How Develocity Works

7.1 Fundamental operating model

7.2 The main components

7.3 Understanding a Build Scan

7.4 Understanding Build Cache

7.5 What happens when Develocity is unavailable?

7.6 Where state lives

Chapter 8. Core Features Explained Simply

8.1 Essential and everyday features

8.2 Acceleration features

8.3 Advanced and enterprise features

8.4 Newer integration capabilities and limitations

8.5 Licensing and feature availability

Chapter 9. Similar Tools and Alternatives

9.1 Comparison

9.2 Which tool should you choose and why?

Part III — Architecture and Workflows

Chapter 10. Architecture Explained from Simple to Advanced

10.1 Architecture level 1: A single developer

10.2 Architecture level 2: Small-team deployment

10.3 Architecture level 3: Production Kubernetes environment

Component responsibilities

10.4 A major architecture consideration: Edge versus legacy Build Cache nodes

10.5 How architecture changes as usage grows

Chapter 11. The Complete Workflow

11.1 A normal build

11.2 A typical sequence diagram

11.3 Failure handling

11.4 How to verify workflow success

Chapter 12. Where Develocity Fits into a Larger System

12.1 Upstream and downstream relationships

12.2 Integration examples

12.3 Responsibility boundaries

Part IV — Installation and First Success

Chapter 13. Prerequisites and Environment Preparation

Path A — Learn locally

Path B — Enterprise deployment

13.1 Minimum requirements for the local labs

13.2 Local hardware

13.3 Private server requirements

13.4 Network considerations

13.5 Pre-installation checklist

Local lab readiness

Chapter 14. Installation on Windows, Ubuntu, macOS, and Linux