We're excited to announce Develocity 2026.2, which offers powerful new features and enhancements designed to increase the efficiency, observability, and governance of your software delivery.

Key highlights include:

• Build Caching Optimizer: The Build Caching Optimizer equips AI agents with the tools and expert-level build knowledge needed to autonomously troubleshoot build cache misses and speed up your builds.
• Expanded Artifact Cache Coverage: Artifact Cache now covers SonarQube quality gate tooling and Maven snapshot dependencies, enabling ephemeral CI builds to start faster and reducing their coupling to upstream repositories.
• Track Upstream Repository Impact on Build Performance: Pinpoint which upstream repositories degrade your builds across the organization with the new Repository Stability dashboard in Develocity Analytics.
• Develocity Provenance Governor Enhancements: Develocity Provenance Governor now brings together attestations from external tools and partners, and makes that data easier and more secure for AI agents to work with.

The Build Caching Optimizer keeps your builds fast and your CI costs down — without depending on scarce build experts. It equips your AI agents with the tools and knowledge to autonomously troubleshoot build cache misses, an expertise that used to require deep, hands-on familiarity with build internals.

The Build Caching Optimizer is an agentic skill that combines Build Scan® data with build-tool domain knowledge to pinpoint why a Gradle task or Maven goal missed the cache. It also recommends the change that makes them cacheable again. AI agents can now run the diagnosis and apply the fix autonomously, so cache tuning no longer depends on a specialist. Whether you're adding caching to a new build or keeping an existing build fast — healthy builds have never been easier to achieve.

This skill works hand in hand with the new Build Scan comparison tool from the Develocity MCP Server. Agents can compare two builds directly to identify exactly which inputs changed, and why a task or goal was not served from the cache. Grounding the diagnosis in detailed build data from Develocity makes it more precise, more reliable, and faster than a generic AI agent.

See the Build Caching Optimizer installation instructions to add the skill to your AI agent.

Artifact Cache expands its coverage to SonarQube quality gate tooling and adds support for caching Maven snapshot dependencies, making CI executions more predictable and reliable.

On a cold start, builds that enforce SonarQube quality gates normally download the SonarScanner CLI, its JRE bundle, and language analyzer plugins from remote servers. Artifact Cache now stores and serves these artifacts independently of the build tool used. This reduces external network dependencies for quality gate enforcement.

With this release, you can also choose to cache Maven snapshot dependencies, so they don't get re-downloaded from upstream repositories on every build. The configured Maven update policy decides when a build checks for an updated snapshot. For example, under the default daily policy, a snapshot published today is picked up by the first CI build the next day. Caching pays off whenever a bounded integration delay is acceptable: for snapshots that rarely change, and for fast-moving ones where waiting for the next update window is fine.

To use these features, update the Artifact Cache CLI to version 1.3.0 or later; no Develocity upgrade is required. See the Artifact Cache CLI compatibility matrix for supported version combinations.

Upstream repositories that rate-limit, time out, or return server errors cause build failures or build time increases that are easily mistaken for problems in your own code. The new Repository Stability dashboard available in Develocity Analytics aggregates dependency download failures across all builds and projects, categorizes them by failure type, and trends them over time across all environments—CI and local. This makes it possible to distinguish a transient incident from a repository that is consistently degrading, and to confirm whether a wave of failures originated upstream rather than from a code change.

Through Develocity Analytics MCP Server, the same data is queryable in plain language by engineers and AI agents alike.

Develocity Provenance Governor helps you automate Governance, Risk, and Compliance (GRC) across the software supply chain. This release broadens the provenance it can capture and makes that data easier and more secure for AI agents to work with.

Compliance proof now extends beyond build data. Fact Connectors pull facts from any HTTP API into the Fact Store, giving auditors a tamper-proof trail across your toolchain.

Define each Fact Connector in a policy YAML file. The connector matches artifacts by annotation, calls your API, and stores the response as an attestation, with no custom code to write.

For example, a Fact Connector can:

• Verify that each artifact links to an approved change request in your ticket system.
• Confirm a library has passed its quality gate before promotion.
• Run a compliance scan and record the result as tamper-proof facts.
• Check that an artifact exists in your binary repository before release.

Leverage AI agents to triage vulnerabilities, assess their impact on your application, and produce an upgrade plan in a single conversation. Instead of switching between dashboards, spreadsheets, and advisory databases, your team gets a structured remediation plan in minutes.

The Develocity Provenance Governor inspect-package-supply-chain MCP tool gives your agent the data it needs at each step. The agent retrieves vulnerabilities with severity and CVSS details, reads full advisories for each CVE, and traces which dependencies carry them. It then filters available upgrades by strategy: patch, minor, or major.

An agent queries the MCP tool and gets back a remediation plan. The answer names which vulnerabilities affect which dependencies, which upgrades resolve them, and what to address first.

AI agents now authenticate to the Develocity Provenance Governor MCP Server using the same identity provider your organization already trusts. You no longer need to manage static API keys or maintain separate credentials for agent access. Teams that use OpenID Connect (OIDC) connect their provider once, and every agent session inherits the permissions.

The MCP server accepts both JSON Web Tokens and opaque tokens. Your existing access control policies govern what each agent can query, with scoping per package. You can also pair HTTP Basic credentials with OIDC in a single configuration.

Identify network dependencies and bottlenecks quickly with precise attribution in the Performance > Network Activity tab. You can now drill down to per-repository breakdowns of GET, HEAD, missing, and failed requests, along with downloaded file counts, data volume, and serial vs. wall-clock time.

Gradle configuration time on ephemeral CI agents drops further now that Setup Cache caches the shared build logic in buildSrc and included builds. That logic, which almost every non-trivial Gradle project relies on for convention plugins, custom Gradle plugins, and shared build conventions, no longer recompiles on every run.

This matters most to Platform teams accelerating builds across the organization: the savings now apply as a baseline to every project, regardless of whether it has adopted Build Cache.

You can now diagnose timing-dependent test problems and understand how distributed test execution unfolds, directly in a Build Scan. A new Test Execution Timeline for Gradle and Maven shows when each test ran during the build, surfacing timing and concurrency issues that are hard to see from test results alone.

Quarkus tests now complete faster: Test Distribution runs them in parallel across a shared pool of remote agents, for both Gradle and Maven. Test suites that previously ran on a single machine can now scale out, reducing CI and local execution times.

Teams with large Quarkus test suites benefit most, especially when those tests account for a significant share of build time. Quarkus 3.31.1 and later is supported.

You can now open up a Build Scan comparison instantly with the new quick compare shortcut embedded directly in the Build Scan Summary.

Simply copy the Build Scan ID with the new Copy Build Scan ID button.

Paste the Build Scan ID or an entire Build Scan URL to the comparison widget and immediately open a side-by-side comparison, all without making the round-trip through the scan list.

You can now spot and investigate outliers, incidents and other short-lived trends better by switching to hourly chart data in the Trends dashboard.

You can easily focus on areas of interest in the "Test class setup/cleanup" view now with the added support for showing and hiding selected distributions. Simply click on the chart legend to configure the visualization.

You can now investigate the cache effectiveness of your sbt build with ease and quickly identify where to make the biggest impact on improving build times.

By utilizing the new Cacheability filter on the Build Scan timeline, you can distinguish between cacheable and non-cacheable tasks to understand their current cache coverage and identify optimization opportunities. The FROM-CACHE outcome filter surfaces tasks successfully served from the cache, while the task details provide in-depth cacheability data.

To streamline your workflow, the Performance section's Task Execution page now provides direct links to these specific tasks on the timeline.

You can now quickly connect to both the Develocity MCP Server and the Develocity Analytics MCP Server for Athena-backed analytics with a single combined configuration.

Develocity ships with two MCP servers for working with Build Scan data: the Develocity MCP Server for individual builds and the Develocity Analytics MCP Server for cross-build trends. Until now, both required their own, separate endpoints, each meaning an extra setup step. Now, both build and analytics capabilities can be reached simply through one unified MCP interface.

Reporting Kit users continue to use the separate Develocity Analytics MCP Server included with their Reporting Kit installation.

New permissions now enable a better security posture by providing more granular control for accessing MCP tools, removing the need for overly permissive grants.

Access to MCP tools is now controlled by a dedicated permission instead of relying on the general API access permission, supporting clear and granular intent when granting one of these permissions.

Another new permission introduces cross-project, read-only access, which is a prerequisite for the Develocity Analytics MCP tools. This removes the past requirement of granting the general, all-access permission and the unnecessarily elevated write-access.

The automated migration of existing roles and permissions is explained in the upgrade guide.

Test Distribution agent capabilities that don't match their pool configuration are now highlighted, making their identification less time consuming, less error prone, and simpler to action.

Administrators now always see the accurate state and source of the SSL Trust configuration and no longer face the risk of mixing up conflicting settings. When the trust configuration is managed by Helm, the admin panel automatically becomes read-only and prevents any misinterpretation.

To assist with this transition, the panel includes a clear deprecation notice and a link to the relevant documentation.

Ensure the following versions are installed to have the best experience and full compatibility with the latest features:

• Develocity Gradle plugin: 4.5.0
• Develocity Maven extension: 2.5.0
• Develocity sbt plugin: 1.4.5
• Develocity npm agent: 4.1.1
• Develocity npm agent loader: 1.0.0
• Develocity Python agent (beta): 0.10
• Develocity Edge: 2.2.0
• Develocity Test Distribution agent: 3.8.0
• Develocityctl: 1.23.0
• Develocity Reporting Kit: 2.3.0
• Develocity Reporting Dashboards bundle: 1.10.0
• Develocity IntelliJ plugin: 1.3.1
• Develocity Provenance Governor: 1.9.0
• Develocity Artifact Cache CLI: 1.4.0

Ensure you are using the latest version of the Develocity plugin for your CI provider:

• Gradle Jenkins plugin
• Develocity TeamCity plugin
• Develocity Bamboo plugin
• Develocity GitLab templates
• Develocity GitHub Actions

Under the Supported Develocity Versions policy, all Develocity releases older than 18 months are not supported. We encourage all users to upgrade to a supported version to receive feature improvements, maintenance updates, and security fixes.

Support for the Develocity Build Cache Node component will end on December 31, 2026. Consequently, versions of Develocity starting with 2027.1 will no longer include or support this component.

Action Recommended: Begin migrating the deployments from the Develocity Build Cache Node to Develocity Edge. Develocity Edge offers the identical remote build caching service, but is designed for enhanced resiliency, scalability, and easier operation. Develocity Edge also serves as the infrastructure foundation of the Develocity Universal Cache platform, enabling you to benefit from a unified caching experience during the entire build life cycle across your entire software supply chain.

The Develocity Edge User Manual contains everything needed to configure and operate Develocity Edge.

Develocity supports storing data in a user-managed PostgreSQL database. We will remove support for PostgreSQL 14, which is reaching its end-of-life in November 2026, in Develocity 2026.4.

Action Recommended: Upgrade to a more recent, supported version of PostgreSQL (15, 16, 17, or 18).

See the PostgreSQL versioning page for more information. Contact us with any questions.

For customers using Develocity Reporting via Amazon Athena, the Develocity MCP Server now serves a combined set of Develocity and Develocity Analytics MCP tools under /mcp. To reduce end-user friction after upgrading Develocity, the /drv-mcp endpoint continues to work, meaning users can update their MCP configuration at their own pace. We will remove the /drv-mcp endpoint in Develocity 2026.3.

Action Recommended: MCP users should remove remote MCP server configurations pointing to /drv-mcp in favor of using /mcp instead.