Decouple Engineering AND Product NAMES

Andi Lamprecht ·2026-05-11· 3 min read· Accepted

Decouple Engineering Resources from Product Names

Context and problem statement

Engineering resources should use unique, internal only names that do not reference external product names. By decoupling resource naming, engineering resources will not need to change to align with changing product concerns.

Leagues are a product facing concern intended to encapsulate the resources supporting a specific product. As such, they should not be used as an identifier inside of engineering.

Decision driver

• Scalability
• Maintainability
• Automation
• Searchability

Decision

Base infrastructure resources will not include the league name as a part of the name, because re-naming can require re-creation of the resource which can lead to data loss or a need for migration process.

In order to de-couple league name and resource name, a random string will be generated as a part of automation and used for replacement of league name in various resources.
Random string will be generated by Terraform resource random_pet, as it can provide human readable name which will be easy to recognize and compare.

The GCP project name will have the following format:
droneup-${_random_string_}-{_env_}

droneup prefix is used as de-duplication string to make sure we will never overlap with the existing GCP project in the world.

But at the same time league name metadata can be assigned as a tag on GCP resources to allow tracebility, maintainability, cost management control. It also can be updated in any moment of time or additional tags can be added. The tags on GCP resources can be involved in networking setup to allow or deny traffic to specifc resources or organize additional IAM management.

Github repositories and depdendent resources will use random string as a prefix or suffix of repository name (as well as CircleCI and Doppler project). The random string will be individual for every new repository and it won’t be related to the name of GCP project.
The GCP project names and league name will be added to the repository as metadata called topics. Topics can be changed in any moment of time and doesn’t require repository re-creation. They allow searching for the repositories under the same league or deployed to the same GCP project.

All league-aligned infrastructure resources that was already created will stay as it is and won’t be re-created from scratch. Any new league or application setup will follow new naming strategy once implementation on this ADR is done.

Considered options

1. Use different random strings for GCP infra creation and application repository setup.
2. Use a random string for GCP infra creation and pass it to the application creation process.
3. Always include league name in GCP and Repository naming.

Pros and Cons of the Options

Different random strings for GCP infra and application repository

Pros:

• League name change doesn’t require resource migration or re-creation
• Application can be migrated from one product/league/team to another

Cons:

• Looking at the resource doesn’t provide the context around the product where it is used
• More steps required to search for the necessary repo or project

Random string for GCP infra creation used in application name

Pros:

• One string to remember that relates to the league
• League name can change without impact on infra and a need of resource re-creation

Cons:

• Looking at the resource doesn’t provide the context around the product where it is used
• Application migration between leagues will require repo re-creation

League name in GCP and Repository naming convention

Pros:

• Standard unified naming
• Easier search
• Self-explanatory resource names

Cons:

• League name change requires resource/infra re-creation from scratch
• Application migration between leagues require repository re-creation, secrets re-configuration, moving code base.

Links

• GCP tags
• Github topics