Announcement: Config as code enhancements, including support for labels and custom fields

[#1]

Hey everyone, Josh here from the Compass product team and I’m really excited to share that config as code now supports managing component labels, custom fields, the lifecycle attribute, and changing component type!

Config as code is a way to describe and manage your components using a "compass.yaml file" that gets added to your git repository. When a component is managed by config as code, it’s catalog information can only be updated by committing changes to the yaml file, which allows for governance over who can make changes and version control of component metadata.

The example yaml file below demonstrates how to use the new features if you’re already familiar with config as code. Checkout our docs for complete details on how to get started with config as code including more information on how to use these new fields.

configVersion: 1
name: example-service
id: 'ari:cloud:compass:d7141038-29ed-438b-901a-cebe65515bab:component/0fa12d64-d15f-4b2e-96fb-5b84203bf3c9/2b5abb73-0a29-465a-8bfd-afc69e5af0e8'
description: This is an example service.
typeId: SERVICE
ownerId: null
fields:
  tier: 4
  lifecycle: Active
links:
  - name: Source Code
    type: REPOSITORY
    url: 'https://bitbucket.org/example/service'
labels:
  - 'foo:bar'
  - baz
customFields:
  - name: platform
    type: text
    value: web
  - name: reviewed
    type: boolean
    value: true
relationships:
  DEPENDS_ON:
    - 'ari:cloud:compass:00000000-0000-0000-0000-000000000000:component/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-00000000000'
    - 'ari:cloud:compass:00000000-0000-0000-0000-000000000000:component/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-00000000000'

# Learn more about formatting compass.yml:
# https://go.atlassian.com/compass-yml-format

You may also notice that we now have a "configVersion" key as well; this is currently optional and the only supported "configVersion" today is "1".

What’s next for config as code you may ask? Next up we’ll be working on allowing you to create new components by simply adding a compass.yaml file to your repository which means we’ll remove the requirement to first create the component in the UI to obtain the ARI.

If you aren’t already managing your components through config as code learn more about it today! Let us know what you think and what else you’d like to see config as code do.

[Richard Simpson]

> Next up we’ll be working on allowing you to create new components by simply adding a compass.yaml file to your repository which means we’ll remove the requirement to first create the component in the UI to obtain the ARI.

Heck yah! We honestly decided against config-as-code because of this requirement. Dropping the requirement for ARNs (including owner refs and component refs!!) would def make use reconsider that.

Also would add that it'd be great to have a yaml JSON Schema so that developers editing the config in an editor like VS Code can get a rich auto complete and validation experience. ++ If it's an extension.

[Josh Campbell]

AWESOME idea thanks Richard!

Hear you on the ID requirement for sure, I'm really excited to ship the create from yaml work myself! Hope you get back around to config as code after we ship it :)

[Thom Smith]

Hey, I've been evaluating implementing Compass within my organisation and the biggest thing that is putting me off is the opaque ARI IDs that are used for teams and other components.

The UX for a developer maintaining the compass.yml, seems very poor in this regard, forcing developers to go look up these IDs. Removing the requirement of the "id" field and the component to be first created in the UI is a good start but the "depends_on" and ownerId" fields should also be human-readable fields.

[Josh Campbell]

Hey Thom! The ability to create a new component without first getting an ARI is imminently coming - the team is hard at work wrapping this up as we speak!

I hear you on the ARI pain. We are very aware of this. The ID is useful because if the name of the owner team or a dependency changes you don't need to update your yaml file. And component names are not unique in Compass as well so again ID is helpful here. But obviously the ARIs are unwieldy and not human friendly, and it also requires you to hit the UI or API (another step) to find these things.

What if you could annotate the owner and dependency fields with a string? So you would still need to add the ARI but you could also add an "alias" key, then while reading the yaml you have a human friendly reference. Helpful for readability?

I assume the preference would be to just be able to use strings and declare the team of the team or component? Somewhat related... do you have components in your catalog that share the same name? Looking to understand how many customers appreciate the fact that the Compass catalog does not enforce uniqueness of component names.

Thom very much appreciate you raising this, it really helps with prioritizing when we hear how painful something is and your feedback is super valuable. Cheers!