This guide covers how to get started with Develocity, with topics such as strategies for incrementally introducing build scans usage and key build scan features for improving your development productivity.
Develocity provides a Build Scan feature. A Build Scan is a permanent and shareable record of an executed build that allows collaborative troubleshooting and optimization.
Installation
This guide does not cover installation of Develocity. Please consult one of the following installation manuals for help with installation:
The remainder of this guide will assume that your installation has a public hostname of develocity.mycompany.com and has enabled HTTPS.
Build Scan
Build scans are a significant innovation in software build tooling. Having centralized and shareable records providing fine-grained details and insights of all builds, including local development builds, enables new levels of collaborative debugging and optimization.
Configuring Bazel
Follow the instruction in the Bazel configuration Guide to modify your project’s .bazelrc file to use with Develocity.
At a minimum, unauthenticated build scans require the following configuration in your .bazelrc file:
common:develocity --remote_cache=grpcs://develocity.mycompany.com
common:develocity --bes_results_url=https://develocity.mycompany.com/build/
common:develocity --bes_backend=grpcs://develocity.mycompany.com
build --config=develocityGiven the above configuration, you can now run your build as usual. As the build completes, the last lines of the output will be similar to:
INFO: Streaming build results to: https://develocity.mycompany.com/build/f26e14c5-dfab-4725-8a77-648f4f8a0ff9The last portion of the URL is the Bazel invocation ID. Follow that link to view your build scan.
Additional information about configuring Bazel to use Develocity’s authentication keys, use the Develocity remote cache, and set project names for project-level access control is available in the Bazel configuration guide.
Build scan highlights
Find and view any build scan
Search through all the captured build scans by going to https://develocity.mycompany.com/scans.
This view allows searching by various criteria, including top-level project name, user name, build outcome, build start time and more. By default, the list is sorted to show the most recent scans first.
Beyond looking for a particular build scan, the listing can provide new insights into the actual builds being run at your organization and by your colleagues. You may find occurrences of previously unknown errors with your build, or that the build is taking longer in certain cases than you expected, or that certain build users are executing more commands than they need to and are therefore subjecting themselves to excessive build times, and other previously unknown behaviors.
Share console logs
Build scans include the console output produced by the build. Many tools used by the build, such as compilers, often write diagnostic information to the console log.
Use the left navigation menu to visit the Console log section.
Click on any line to highlight it or shift-click two different lines to highlight a block of lines. Note that the browser’s current location has been updated. By sharing that URL with a colleague, you can direct them to the exact console output that you wish them to see. Many aspects of build scans are directly linkable to facilitate sharing and collaboration.
Inspect test results
If your build executed tests, then their results will be included in your build scan. Use the left navigation menu to visit the Tests view.
This section shows the results of all the tests that ran during your build, along with their outcome and durations. The results are broken down by target, test suite and test case. Select any test suite or test case to see details about each of their individual executions, in case of test retry.
Different durations are available for targets, test suites and test cases:
|
Total time |
Generally corresponds to the wall clock time that an execution lasted. |
|
Own time |
Time spent preparing for the actual work, such as preparing your framework. |
|
Serial time |
Time the operation would have taken if all its sub-steps occurred sequentially. |
| Under some circumstances, some durations may be missing. |
Analyze build performance
A key benefit of build scans are the various insights they provide into build performance. Many builds provide different functions for different people and will perform differently on different machines. Having deep performance insights available for every build enables optimizing all corners of the build, for all users.
Use the left navigation menu to visit the Timeline view.
This section provides insights into the event executions, visualizing them as a timeline. This representation clearly shows the parallel utilization of your build.
The table below the graph provides a concise breakdown of the events executed during the build. The table provides more detail on individual events (click the 
icon when hovering over an event) and can be used to understand dependencies between events.
The Critical Path tab shows the longest chain of dependent actions with regard to execution time. It is an estimation of the shortest possible build time if infinite compute resources were available, and all non-dependent actions were executed in parallel.
Next steps
Custom tags, values and links
Build scans can be enriched with metadata particular to your environment by several means. Extending your build scans with tags, values and links is strongly recommended. In particular:
-
VCS information such as commit identifiers, branch names, etc.
-
Tags for different types of builds (e.g.
CIvs.local) -
Links to CI system record of build for CI builds
This adds useful context to your build scans, and allows you to search and filter based on this metadata.
Integrating your CI tool
Build scans are passive with regard to the build process. That is, enabling build scans does not affect the outputs of your build. It is generally safe to simply add the necessary configuration to your projects to enable sending build scans to your Develocity installation and check it in to version control, enabling it for all users of the build.
However, it is important to note that with Bazel, there is the potential that connectivity errors to Develocity could cause the Bazel command to return a non-zero exit code, potentially impacting the outcome of the build. If there is no connection available when Bazel tries to publish to the Develocity Build Event Server, Bazel will exit with code 38 and display a message similar to the following:
INFO: Build completed successfully, 1 total action
ERROR: The Build Event Protocol upload failed: All 4 retry attempts failed. UNAVAILABLE: develocity.mycompany.com UNAVAILABLE: develocity.mycompany.comAt the time of this writing, the Bazel client does not yet offer a configuration option to fail gracefully in these instances.
Getting help or asking questions
If you are currently using Develocity as part of your trial sign-up or license purchase, you received instructions on how to access the priority Develocity support channel. If you have any issues with or questions about Develocity, please raise a support request.
Alternatively, or if you are not yet using Develocity, you can use the Gradle discussion forum if you are able to discuss your issue publicly. If you are unable to discuss your issue publicly, please use our contact form.
Keeping up to date
Develocity is constantly evolving with regular updates that add new features and capabilities. The monthly Gradle newsletter is an easy way to stay informed about new releases, features and events.