Unleash your (Custom Field) creativity

[#1]

Stage 1: You can (right now) create Custom Fields via Compass' APIs. Add text, number and boolean types, assign them to different types of Components (Services/Libraries/Applications/Other). Instructions below…

Stage 2: We're mid-build on the Custom Field management UI — create, edit, assign & delete custom fields through the web UI… landing mid June.

Stage 3: CUSTOM FIELDS IN SCORECARDS Y'ALL! Bring the power of Scorecards to the flexibility of Custom Fields! This changes everything. It allows you to integrate other tools or processes into Compass Scorecards, co-mingle them with Metrics and create expressive, consistent policies which join up data from anywhere in your organisation.

Things you'll need to get going:

1. <Site>: Which site are you running Compass on? <Site>.atlassian.net
2. <API Token>: Head to https://id.atlassian.com/manage-profile/security/api-tokens and create a new API token — name it anything you like (I called mine "Tacotoken" 🌮). Copy it and keep it safe!
3. <Email>: We'll also need the email address used with your Atlassian account — you can double check it at https://id.atlassian.com/manage-profile/profile-and-visibility
4. <Cloud ID>: Grab your Cloud ID — run this and look for the cloudId value.

curl -u "<Email>:<API Token>" --request POST \
  --url https://api.atlassian.com/graphql \
  --header 'Accept: application/json' \
  --header 'Content-type: application/json' \
  --data '{"query":"query cloudIdByHostname($hostname: String!) {\n tenantContexts(hostNames: [$hostname]) {\n cloudId\n }\n}", "variables": {"hostname": "<Site>.atlassian.net"}}'

Right! Let's put it all together in a taco-themed example:

curl -u "<Email>:<API token>" --request POST \
  --url https://api.atlassian.com/graphql \
  --header 'Content-Type: application/json' \
  --header 'X-ExperimentalApi: compass-beta' \
  --header 'X-ExperimentalApi: compass-prototype' \
  --data '{"query":"mutation createCustomFieldDefinition($input: CompassCreateCustomFieldDefinitionInput!) {\n compass {\n createCustomFieldDefinition(input: $input) {\n success\n errors {\n message\n extensions {\n statusCode\n errorType\n }\n }\n customFieldDefinition {\n\t\t\t\t__typename\n id\n name\n description\n\t\t\t\tcomponentTypes\n }\n }\n }\n}","variables":{"input":{"textFieldDefinition":{"cloudId":"<Cloud ID>","name":"Favourite taco?","description":"Al pastor is probably the right answer.","componentTypes":["APPLICATION","SERVICE"]}}},"operationName":"createCustomFieldDefinition"}'

Okay, okay, okay, okay, okay… maybe you're nope-ing out on having to make an API call. Luckily you don't have to wait until Stage 2 is released (again, mid June!). We made an internal UI for testing & development purposes and decided to live up to the Alpha in our name. So here it is: https://<Site>.atlassian.net/compass/custom-fields. It won't last long, just until the real admin experience is shipped, but it'll get you going today.

Aaaaaaaand… that's it! Now you can figure out just what kind of tacos each of your components prefers. If that's not worth the price of entry then I don't know what is.

What are you going to use Custom Fields to enable in Compass? We'd love to hear from you — help us shape this feature and make sure Compass works just the way you need it to!

[Andrew Freedman]

Did I say "mid June" for stage 2? Doubtful, I'm quite certain I said "early July". ;)

But last week we shipped the full config experience and here's @shafqat with a cracker demo of Compass Custom Fields!

Cast off the onerous yoke of curl! (Unless you prefer it, in which case, keep hauling that yoke!)

[Pete Capra]

Hi @Andrew Freedman - any update on Stage 3? Cheers!

[Andrew Freedman]

Very soon! It's dropping in about three weeks.

What are you planning to use custom fields + scorecards for? Always keen to hear more. :D

[Pete Capra]

That's great news! It's very early days for us, but we're keen to see whether we can use Compass to help track tech debt in the form of unsupported frameworks and in some cases small apps in programming languages we'd like to move away from. 

As an extension to this, it would be awesome if we could track 3rd party libraries/dependencies too so that we could get better visibility and management of them also. 

[Andrew Freedman]

This is something we definitely want Compass to solve for customers. When Log4Shell hit we saw that as a clear example — every CTO immediately needed to know which of their systems were impacted and track how quickly they were able to upgrade.

But even when there's not an urgent vulnerability, it's exactly as you describe. How are we going with framework consolidation? What does our tech stack look like versus our ideal? How quickly is that changing? Custom fields (and very soon CFs + scorecards) are definitely the right approach for now.

In future we think we want to introduce the idea of "external" dependencies — so maybe you've got a component called frontend and it uses grunt. We're thinking about building something like an npm integration so that you can pick a new upstream dependency (or we find it through code analysis) and link frontend -> grunt (npm). We'd then be able to suck in version information, contact info, etc, etc.

[Pete Capra]

Yes, exactly @Andrew Freedman . It might also be helpful to have 'version' as a first class field for a dependency. When enhancements are made it to libraries it would be great to know which services and applications have adopted (and released to production) the latest version and which still need to upgrade.