Develocity Upgrade Guide

The Pod Identity authentication can now be used to authenticate AWS services like S3, RDS, etc. AWS EKS Pod Identity provides a way to manage IAM permissions for applications running in your EKS clusters by associating IAM roles directly with Kubernetes service accounts, similar to IRSA. IRSA will continue to be supported.

No immediate action is required, but you can start using this feature to simplify your AWS service authentication. See values file example for more details on how to configure Pod Identity in your values.yaml file.

The Alpine-based container images are no longer available in the Develocity distribution.
Usage of Alpine images has been deprecated since 2024.3.

You will get an error message if you try to use the Alpine images.

Error message:

Please contact Develocity customer support before trying to switch it off. If you don’t follow the right process, you may end up with a corrupted database.

The readOnlyRootFilesystem setting is now enabled by default for all Pods in the Develocity deployment. This enhances security by preventing unauthorized modifications to the root filesystem of the Pods. No action is required.

The JVM heap allocation is now automatically configured based on the available resources in the Kubernetes cluster. This change simplifies the configuration process and optimizes resource usage.

The JVM Heap memory settings in the unattended configuration are ignored for cluster deployments.

No immediate action is required. We recommend reviewing the resource settings in your values.yaml file to ensure they align with your resource allocation strategy.

Develocity and Edge nodes connect using the gRPC protocol. Nothing needs to be done unless you are using Edge nodes with Bazel integration. If that’s your scenario, configuring the gRPC connection might require specific attention, so please contact the Develocity customer support for assistance.

When running in standalone mode, non-critical components (metrics, monitoring, operator, proxy) are resource-restricted. This change ensures that non-critical components do not consume excessive resources, improving overall system stability and performance.

This change is applied automatically. The default resource requests and limits are usually enough for standard deployments. However, if you observe issues related to those resources, you may need to adjust the settings. Below you can find an example for the operator; please consult the values file example for more details on other components' configuration.

The version check for Kubernetes and Helm during the installation process has been relaxed. This allows for a wider range of versions to be compatible with Develocity, making it easier to upgrade without strict version constraints. No action is required.

Users can now define their own Pod Security context. This change provides greater flexibility in configuring Pod Security, enabling compliance with stricter security policies (e.g., OpenShift’s restricted-v2 SCC) and better integration into environments that utilize arbitrary user IDs for containers. If you require a custom Pod Security context or are deploying into an environment like OpenShift with restricted-v2 SCC, you can now define your desired securityContext. See the Kubernetes Security Context for more details. For information on OpenShift Security Context Constraints (SCC), refer to the OpenShift documentation.

The creation and maintenance of the schema used by Develocity Reporting via AWS Athena can now be managed entirely by Develocity. Once configured, Develocity will ensure that the right version of the schema, along with any updates, is set up for AWS Athena. This greatly reduces the effort needed to set up and maintain Develocity Reporting. The installation manual provides further details on how to enable this feature.

Following the announcement of the Build Cache Node deprecation starting with the Develocity 2027.1 release, we strongly recommend that users of the Develocity Build Cache Node start migrating their deployments to Develocity Edge. Develocity Edge serves the same purpose as a remote build caching service for your build agents, but is designed to be simpler and more robust to operate. The Develocity Edge User Manual migration guide provides all the information you need to migrate existing Build Cache Nodes to Develocity Edge.

Upgrading an airgap instance of Develocity requires downloading the latest version of charts, transferring them to the host machine, and installing them. Downloading an update for Develocity requires your license file.

If you have configured more than one replica, you must scale the replicas down to one before upgrading to avoid having mixed versions running simultaneously.

Upgrading an airgap instance of Develocity requires downloading the latest version of charts, transferring them to the host machine, and installing them. Downloading an update for Develocity requires your license file.

Use case: You want to upgrade but keep all the values from the current deployment without any modifications.

This is useful to ensure that existing values remain unchanged during an upgrade.
This is the most straightforward option if no configuration needs to be modified.

Use case: You have an existing configuration and want to update the license value and disable ingress SSL, but keep the rest of the configuration.

Use case: You want to upgrade to Develocity 2025.2 and adjust the Object Storage configuration (see the example above).