Skip to main content

Start to enable your experts to manage maturity progress

Introduction​

As your organization continues to mature in its adoption of Soundcheck, being able to effectively manage your Checks and Tracks in Backstage becomes an important part of your adoption maturity.

It's common for many organizations to ask the team implementing Backstage within their organization to manage the Tracks in Backstage. However, empowering other teams to implement their own Tracks can improve each adopting team’s experience using Backstage.

In this tutorial, we'll walk through the available ways to manage Checks and Tracks in Backstage.

Requirements​

  1. Completed Soundcheck Backend Setup
  2. Completed Soundcheck Frontend Setup
  3. While not necessary, it is recommended to complete one of our supported SCM-specific prerequisites

Understanding the Various Methods of Managing Checks and Tracks​

Soundcheck allows you to manage your Checks and Tracks via the UI and or by YAML. There are tradeoffs for each of these methods which we’ll highlight below. Additionally, all of these methods can be utilized together so each team implementing these can pick the best method for the team on organization.

Managed Via Local YAML​

If your organization has followed one of the SCM-specific prerequisites, then you are already familiar with defining Checks and Tracks via YAML.

Pros:

  • Can be stored with your organization’s core Backstage implementation in source control.
  • Can be stored in a different file from your app-config and included using the $include directive, making it portable across environments.
  • Simplifies “cross-team” Checks as all Checks are local and there is no concern about a specific Check id not being valid.

Cons:

  • Pull requests for changes or additions to Checks and Tracks can get bottle-necked if a single team manages your organization’s Backstage implementation.
  • CI/CD pipelines have to be considered to prevent unnecessary work when making changes to just the yaml file.
  • Changes to the checks and tracks requires Backstage to reload the yaml files. This can be accomplished via the refetch config or by restarting your Backstage instance(s).

Managed Via Remote YAML​

Managing Checks and Tracks via remote YAML is very similar to managing them via local yaml. The primary difference is the import path added to your Backstage instance via the app config yaml files.

Pros:

  • Multiple teams can contribute their own Checks and Tracks that live in their team’s source controlled files.
  • Can simplify your app-config to include the remote source(s) making it portable across multiple environments.

Cons:

  • If all Checks and Tracks are implemented by teams in their respective repositories then Pull Requests can be merged faster given the scope of work and changes are limited.
  • CI/CD pipelines can be simplified to ignore the yaml files or perform some linting and potentially JSON Schema validation.
  • "Cross-team" Checks become more complicated since a team implementing another team’s Check in their Track must verify the other team’s Check has been included.
  • Changes to the Checks and Tracks requires a restart of the Backstage backend.

Managed Via the Backstage UI​

The Backstage UI allows your teams to manage their respective Checks and Tracks in a more user-friendly way, but with some limitations.

Pros:

  • Does not require a user to know yaml or the Check or Track schema.
  • Checks and Tracks can be implemented in “real-time” without needing to restart the Backstage backend with immediate feedback of affected Entities.
  • Creation and editing of Checks and Tracks can be limited to specific users/groups via the RBAC plugin.

Cons:

  • Not easily portable across environments, since the Checks and Tracks would need to be implemented in each environment.
  • Checks and Tracks can be exported to YAML which makes them more portable

Empowering Teams To Manage Their Own Checks​

Teams can begin to manage their own Checks with relative ease. This allows you to scale the rate of adoption of Soundcheck across your entire organization.

  1. Use a whiteboard session with a pilot team to map out their desired checks.
  2. Review the NCUI to empower them to move this Check pseudocode to a concrete implementation.
  3. Have the pilot team utilize the NCUI to build their checks in the NCUI
    • For instructions on how to build and maintain checks in the NCUI, please go here
  4. Once all of their checks have been created in the NCUI, have them build their Track using the newly created checks.
    • For additional instructions on how to build and maintain tracks in the NCUI, please go here
  5. Now you have your first inner-sourced track and set of checks!