Modeling multi-repo applications in Compass (components vs rollups vs deployment repo)

[Andrew Harmon]

Hi all — I’m looking for advice on whether we’re modeling things “correctly” in Compass, or if there’s a better pattern we should be using.

 Our setup

We use Compass to track DevOps metrics (deployments, PR activity, etc.) across a set of GitHub repositories. The challenge we’re running into is that what we think of as a single application is often composed of multiple components, each living in its own repo.

For example, an application might consist of:

• auth repo – authentication / authorization service
• api repo – backend API
• infra repo – Terraform / Helm / infrastructure for that app 

Conceptually, this is all one “application” from a product and operational standpoint, but in reality it’s split across multiple repos with different owners and lifecycles.

On top of that, we have a fourth repo:

• deploy repo – responsible for actually deploying applications (GitHub Actions / pipelines that reference the above repos)

Because of this:

• PRs happen in the component repos

• Deployments technically happen from the deploy repo

• We’d like Compass to reflect both the individual component health and the rolled-up view of the application as a whole

What we’d like to see

Ideally, we want to be able to:

• View metrics per component (PR frequency, deployment frequency, lead time, etc.)

• Also view those metrics rolled up at the application level

• Avoid duplicating or misattributing deployment events that originate from the deploy repo

• Keep the Compass model intuitive for engineers (i.e., “this is an app made of these components”)

Where we’re stuck

What I can’t quite figure out is the best way to model this in Compass:

• Should each repo be its own component, with an additional “application” component that depends on them?

• How do people usually attribute deployment events when the deployment logic lives outside the app/component repos?

I'm currently using the REST api to post deploys from the deployment repo to each "parent" component that represents an app. Bc an app is deployed with all its parts? Config settings, versions etc get set in this repo then deploy all the components together.

Before we lock ourselves into a structure, I wanted to ask the community how others are handling multi-repo applications and shared deployment pipelines in Compass.

Thanks in advance — appreciate any guidance or real-world examples.

[Tomislav Tobijas]

Hi @Andrew Harmon ,

Based on some fairly basic experience, and on general best practices in this area, my two cents would probably be:

• Each repo (auth, api, deploy) should be represented as its own Compass component > this would cover tracking metrics, ownership, etc., at the individual level
• Application-level roll-up - To represent the "app" as a whole, you could create an additional component of type "Application."
  On top of that, use dependency relationships to link the individual components. This would enable a rolled-up view of the app's health and dependencies. 📈

As for deployment events - these are triggered from the deploy repo, but maybe you could use the REST API to post deployment events to each component that is actually being deployed.
Or, you could also post a deployment event to the "application" component if the deployment represents a coordinated release of all parts.

🤔 This part is a bit theoretical from my side, as I'm still trying to find a use case/client who actually wants to use Compass, so it's fairly based on my playing in sandbox environments.

Lastly, for the application component, you might run into the case that metrics and dependencies are not automatically aggregated (depending on the setup). I'd probably then try to use scorecards and dashboards to visualize that part. 📊

In the end, I'm actually also keen to see if there are any 'live setups' when it comes to this area.

Cheers,
Tobi