Migrations
Migrations involve moving Develocity data or services between different environments or storage architectures.
Unlike routine administration, migrations are point-in-time events that often require downtime and careful data validation.
Migrating from Embedded to User-Managed Database
If your Develocity instance uses the embedded database and you want to move to a user-managed PostgreSQL database (for example, Amazon RDS, Azure Database for PostgreSQL, or a self-managed instance), follow the User-Managed Database Migration Guide.
That guide presents several strategies with different trade-offs for downtime and data retention. For installations with a small database, the simplest approach is the Migrate All Data Up-Front strategy, which copies everything in a single step.
Migrating to Build Scan Object Storage
Develocity can store Build Scan data in an external object store (AWS S3, Google Cloud Storage, or Azure Blob Storage) instead of the database. This is configured through the Helm chart and the Develocity administration interface.
For configuration details, see the Kubernetes Helm Chart Configuration Guide or Standalone Helm Chart Configuration Guide. For guidance on enabling object storage and understanding the trade-offs, see Build Scan Object Storage.
| Built-in Build Cache entries are stored separately and don’t need to be migrated when changing Build Scan storage backends. Cache entries will be repopulated by running the relevant builds again. |
Migrating from Standalone to Kubernetes
If you are moving from a single-host (Standalone) installation to a Kubernetes cluster:
-
Export Configuration: Download your current Develocity configuration from the Standalone UI via . This exports your Develocity settings as a declarative YAML file that can be used with unattended configuration.
-
Plan Your Architecture: Before setting up the cluster, decide whether to use a user-managed database and external object storage. These choices affect how you provision the cluster and what storage is required.
-
Prepare the Cluster: Set up your Kubernetes cluster following the Kubernetes Installation Guide. The Helm chart can optionally create the namespace during installation.
-
Transfer Data: Migrate your database using the User-Managed Database Migration Guide.
-
Deploy via Helm: Use the exported configuration file with your Helm values to deploy Develocity. See Managing Settings via Unattended Configuration for details on applying exported configuration.
Technical Considerations
-
Downtime: Most migrations require the application to be stopped (
develocityctl system stop) to ensure data consistency during the transfer. -
Version Matching: Ensure the target Develocity instance is running the exact same version as the source instance before attempting a data migration.
-
Network Latency: When migrating data between regions or cloud providers, account for transfer time and potential egress costs.
|
If you are performing a complex migration involving multiple architectural changes, contact Develocity support to review your migration plan before execution. |