How Backstage discovers catalog files in Azure DevOps
If your repositories live in Azure DevOps and you want catalog entities without registering each one by hand, Backstage reads catalog-info.yaml files from Azure DevOps through its integration configuration and catalog discovery. The exact module names and configuration keys depend on the Backstage release you run, so confirm them against the current integrations documentation for that release before you write any configuration. Plan for discovery to be a configuration decision you test in a non-production portal first, not a setting you copy from an older example.
Two modes matter here. Reading a specific catalog location points Backstage at one file or one repository path, which is simple to reason about and suits a pilot or a small set of services. Running discovery across an organization tells Backstage to scan many projects and repositories and register every matching descriptor, which scales better but depends on the credential having read access to everything it will scan. Decide early which mode fits your estate, because discovery scope drives both the entity count and the permissions you grant. Azure DevOps Services (the cloud service) and Azure DevOps Server (the self-managed product) are separate targets in Backstage. Each has its own host configuration, and the authentication options differ between them, so do not assume a working cloud setup will carry over to an on-premises server. Ask your Azure DevOps administrators which deployment you run, then confirm which credential types your Backstage release supports for that target and whether your network path from the Backstage backend to the server is allowed.
What you need before connecting Azure DevOps
Five items need an owner and a answer before any Backstage configuration is written. Each one decides whether the catalog reader can reach Azure DevOps, authenticate, and trust the certificate chain. Confirm them in this order, because the Backstage release and Node.js version constrain the rest.
Backstage release and Node.js version
Confirm which Backstage release line your portal runs and which Node.js versions that release supports. The Backstage versioning policy currently lists Node.js 22 and 24 for Backstage 1.46.0, so check the policy for your exact release before you pin the runtime. Ask your platform team whether the backend image uses a supported Node.js major version. A mismatch here breaks the integration package before any Azure DevOps call is made.
Azure DevOps organization and scope
Ask the Azure DevOps administrator whether you are targeting Azure DevOps Services or Azure DevOps Server, because the two differ in hosting and authentication options. Get the exact organization or collection names, the projects, and the repositories that hold catalog-info.yaml files. Discovery only sees what you list, so an unclear project scope produces a catalog that looks incomplete.
Reader identity with repository access
Name the identity that Backstage will use to read catalog files, whether a personal access token, a service principal, or a managed identity. Ask the administrator to grant it read access only to the repositories that hold catalog descriptors, not the whole organization. Confirm who owns the credential, when it expires, and who rotates it, since an expired token silently stops discovery.
Network path from the backend
Confirm that the Backstage backend, not the browser, can reach the Azure DevOps host over HTTPS. Ask the network team whether egress rules, proxies, or private endpoints sit between your cluster and Azure DevOps, and whether the backend runs in a segment that allows that route. Test the path from the same container image and network namespace the backend uses, since a workstation test can pass while the pod fails.
Private certificate authority trust
If Azure DevOps Server runs behind a private certificate authority, the Backstage backend must trust that root and any intermediate certificates. Ask the Azure DevOps administrator for the certificate chain and which authority issued it, then ask your platform team where the trust store is mounted in the backend image. Without it, TLS handshakes fail even though the credential is valid.
Owner for catalog file conventions
Decide who owns the catalog descriptor layout across repositories before discovery starts. Ask the Azure DevOps team which repositories and branches should be scanned, and whether teams already keep descriptors in a consistent location. Agreeing on this now prevents duplicate entities and unowned components later in the catalog.
Choosing PAT, service principal or managed identity
A personal access token (PAT) is the simplest credential to configure. It is issued to a single Azure DevOps user and carries that user's permissions, so Backstage can read exactly what that person can read. The token is typically stored in the Backstage configuration as a secret and referenced from the integration settings. Because it is tied to a person, its owner is the account holder, and its access is only as narrow as the scopes chosen when it was created.
- Ownership: The token belongs to a named user. Use a dedicated service account rather than an engineer's personal login, and confirm your Azure DevOps organization allows service accounts of that kind.
- Rotation: PATs have a maximum lifetime set by the organization policy. Plan a rotation calendar and a secret update in the Backstage deployment, since expiry stops catalog discovery without warning.
- Scope: Grant only the read scopes needed for code and catalog file access. Avoid broad write scopes, because Backstage discovery does not need them.
- When the owner leaves: Deactivating the account revokes the token, and discovery silently fails until a new token is issued. Document the owner and the recovery steps before go-live.
- Multi-organization use: A PAT is scoped to one Azure DevOps organization, so each organization needs its own credential entry.
Confirm the exact scope names, lifetime limits and service account rules with your Azure DevOps administrator before choosing this option.
A service principal, registered through Microsoft Entra ID, lets Backstage authenticate as an application rather than as a person. The application identity is granted access to the Azure DevOps organization, and the credential is a client secret or certificate held in your secret store. This option separates Backstage access from any individual's account and is usually easier to audit than a personal token.
- Ownership: The app registration is owned by the team that operates Backstage, with a named owner recorded in Entra ID.
- Rotation: Client secrets and certificates have their own expiry dates. Prefer certificates where your policy allows, and track expiry in the same process as other service credentials.
- Scope: Add the application to the Azure DevOps organization with only the access it needs, and review project-level permissions for each repository set Backstage reads.
- When the owner leaves: The registration survives staff changes, but the named owner must be updated. Orphaned registrations without an owner are a common audit finding.
- Support check: Not every Backstage Azure DevOps integration version accepts this option for discovery. Confirm it in the release notes or configuration reference for the version you install.
Ask your Entra ID administrator which credential type your tenant policy permits before design begins.
A managed identity removes stored secrets when the Backstage host runs in Azure. The platform issues short-lived tokens to the host's identity, so there is no password or client secret for Backstage to hold. This is the strongest option for secret handling, but it only applies when Backstage runs on Azure infrastructure that supports managed identities and when the integration version accepts that authentication method.
- Ownership: The identity is tied to the Azure resource, such as a virtual machine, container app or Kubernetes workload identity. The resource owner controls it.
- Rotation: There is no secret to rotate. Access control changes are managed through role assignments and the resource lifecycle.
- Scope: Grant the identity access to the Azure DevOps organization and only the projects Backstage must read. Review the assignment whenever the hosting setup changes.
- When the resource leaves: Deleting or recreating the host changes the identity. Plan how the new identity is granted access before the old resource is removed, or discovery stops.
- Hosting limits: If Backstage runs outside Azure, or in an air-gapped or on-premises setup, this option is unavailable. Confirm the hosting model first.
Verify with your platform team which Azure resource type hosts Backstage, and whether your Azure DevOps organization accepts this identity type.
Azure DevOps Server is self-hosted, so the options available on Azure DevOps Services do not carry over automatically. Authentication depends on how your server is configured, which directory it trusts, and whether it can be reached from the Backstage host. Treat this tab as a separate planning exercise, not a copy of the Services guidance.
- Ownership: Credential ownership follows your server administrators and identity team, since they control the accounts and directory the server uses.
- Rotation: Confirm how tokens or secrets are issued on your server version and whether lifetimes differ from the cloud service.
- Scope: Check project and collection permissions on the server itself, because the server may have a different permission model.
- Departure handling: Account removal in your directory affects what Backstage can read, so document which directory accounts the integration depends on.
- Network reachability: Managed identity is generally tied to Azure-hosted services, so confirm whether it applies at all when the server is on premises.
Confirm with your Azure DevOps Server administrator which authentication methods the Backstage integration supports for your server version before selecting any option.
Configuring the Azure DevOps integration in Backstage
This sequence takes Backstage from no Azure DevOps access to a verified read path for catalog files, starting with a scoped identity and ending with one confirmed entity from a test repository. Each step closes with a check so the team knows it can move on.
Create a read-scoped identity in Azure DevOps
An Azure DevOps administrator creates the identity Backstage will use to read repositories. Decide first whether a personal access token, a service principal or a managed identity fits your environment, since the choice affects rotation, ownership and what the credential can reach. Grant read access only to the repositories that hold catalog-info files, and no write or administrative scopes. Confirm the identity can list one target repository in the Azure DevOps interface and that it cannot modify anything, because a token that can write is a larger exposure than the catalog needs. Record the owner and rotation date in your secrets inventory.
Store the credential in the Backstage secret store
Place the token or client secret in your secret manager or in the environment variable mechanism your Backstage deployment uses, and reference it from configuration by name. Keep the value out of app-config.yaml committed to source control, and check that the repository and CI logs do not echo it. Backstage configuration can read secrets from the environment, so the config file should contain only the variable name. The check for this step is a code search of the configuration repository that returns no matches for the token value, and a deployment that starts with the variable set.
Add the Azure DevOps host entry to integrations
A platform engineer adds an Azure DevOps entry under the integrations section of the Backstage configuration, one per Azure DevOps Services organization or per Azure DevOps Server host. Set the host, and reference the credential by its environment variable name. If you use more than one organization, add one entry for each, and confirm with the Backstage integrations documentation how credentials are matched to hosts and organizations in your version. The check is that the backend resolves the integration without a configuration validation error at startup, which you can confirm in the startup log.
Configure discovery for the projects to scan
Add a catalog provider or location entry that tells Backstage which Azure DevOps projects and repositories to scan for catalog-info files, and the file path or pattern to look for. Keep the scope narrow for the first pass, pointing at one project with one known repository. Confirm the exact provider keys and filter options against the Backstage documentation for the Azure DevOps catalog module in the version you run, since these keys change between releases. The check is that the configuration validates and the provider is listed as registered in the backend log.
Restart the backend and confirm the provider starts
Restart the Backstage backend so the new integration and provider configuration load. Watch the startup log for the Azure DevOps provider initializing and for the first scheduled run beginning without authentication errors. A 401 or 403 response in the log usually points to the credential scope or the wrong organization in the host entry, and both should be fixed before moving on. The check is a clean startup log with the provider registered and no repeated authorization failures across the first scheduled cycle.
Run a first discovery against one test repository
Commit a minimal catalog-info.yaml to the one test repository, using a placeholder component name that is easy to recognize, and wait for the next scheduled discovery or trigger one manually if your deployment supports it. Search the Backstage catalog for that name. The check is exactly one expected entity with the source location pointing at the test repository, and no duplicate or unexpected entities from other projects. Only after this passes should you widen the scope to more projects or organizations, and revisit the credential scope if the test surfaces repositories you did not intend to expose.
How Azure DevOps repositories map to catalog entities
This table compares each Azure DevOps object you will configure with the Backstage concept it becomes during discovery. Read it top to bottom to trace one catalog file from an Azure DevOps repository to an entity and its owner. The main takeaway is that ownership comes from identities resolved by a separate org data source and sign-in resolver, so decide which system owns each group before turning discovery on.
| Azure DevOps object | Backstage concept | What to decide or confirm |
|---|---|---|
| Organization or server (Services or Server) | Integration host entry in the Azure DevOps integration configuration | Confirm the host URL and whether you run Azure DevOps Services or Azure DevOps Server, since the authentication options differ |
| Project | Discovery path grouping that limits which repositories the processor scans | Choose which projects belong in the catalog and whether each project is scanned or excluded explicitly |
| Repository | Location a catalog file is read from during discovery | Decide which repositories must carry a catalog file and which are out of scope for the portal |
| Branch and path | The branch and file path the processor reads, such as the default branch and the root catalog-info file | Confirm the branch and path convention so teams know where to place catalog-info descriptors |
| catalog-info kind field | Entity type, such as Component, API, System or Resource | Agree the kinds your model uses before teams start committing descriptors |
| catalog-info owner field | Reference to a User or Group entity that owns the component | Confirm the owner value matches an entity name produced by your org data source, or ownership will not resolve |
| Azure DevOps users and groups | Backstage User and Group entities created by an org data source or sign-in resolver, not by the Azure DevOps catalog read | Decide whether Entra ID, LDAP or another directory owns each group before discovery is enabled, so two sources do not write conflicting groups |
| Personal access token, service principal or managed identity | Credential the integration uses to read repositories, scoped to the projects and permissions you grant | Confirm which credential type your Azure DevOps deployment supports and that it has read access only to the scoped projects |
Multi-organization credentials and on-premises authentication limits
One Backstage instance often needs credentials for more than one Azure DevOps organization or server. Teams that run several Azure DevOps organizations, or a mix of Azure DevOps Services and an on-premises Azure DevOps Server, usually discover this when the first catalog discovery job finds repositories in a second tenant that the first credential cannot read. In the Backstage integration configuration, each host entry carries its own credential reference, so the host, the organization and the secret that authenticates to it are chosen together. Plan the list of hosts and organizations before writing configuration, because a missing entry shows up as silently skipped discovery rather than a clear error in many setups. Confirm with your Azure DevOps administrator which organizations must be read, and which of them share a tenant or identity provider.
A single identity shared across every organization is simpler to rotate but increases blast radius. If one token or service principal secret leaks, every organization it can read is exposed at once, and Backstage's catalog processing will read from all of them with the same permissions. Where your governance allows, use one credential per organization or per server, scope each to read-only access on the repositories that hold catalog files, and set expiry dates you can rotate without a full outage. Keep the secret storage, rotation owner and revocation steps recorded per host entry, since that record is what your security team will ask for.
Authentication options differ between Azure DevOps Services and Azure DevOps Server, so the on-premises limits decide the design. Confirm which credential types your exact Azure DevOps Server version supports for the Backstage integration, and whether managed identity or service principal options are offered only on Azure DevOps Services. Also confirm how the Backstage backend must trust the server certificate, including whether an internal certificate authority must be added to the runtime trust store, since a missing chain typically fails at discovery time. Get the supported method list for your version from the Backstage authentication documentation and the integration reference, then validate it with your Azure DevOps administrator before choosing a design.
Hardening the Azure DevOps credentials in Backstage
The Azure DevOps integration reads catalog files with credentials that can see every repository they are allowed to reach, so the scope of those credentials is the main control. The cards below cover what to restrict, where to store secrets, how to rotate them, and how to watch for misuse. Each control needs sign-off from the team that owns the Azure DevOps organization and the team that runs the Backstage deployment.
Least-privilege read scope
Give the discovery credential read access only to the projects and repositories that hold catalog files, and no write or administrative permissions. This limits what a leaked token can reach and keeps the integration from being used to change source code. Ask the Azure DevOps administrators to confirm the granted scopes in writing and to review them whenever a new project is added to discovery. Approval: the Azure DevOps organization owner and the security team.
Secrets outside catalog files
Store the Azure DevOps token or service principal secret in the secret management path Backstage reads at runtime, and reference it from configuration by name. Never place it in app-config.yaml, in a catalog-info.yaml file, or in a template that teams can read and copy. Catalog files are visible to everyone who can read the repository, so a secret there is effectively published. Approval: the platform team and the security team jointly.
PAT rotation and expiry planning
A personal access token expires on a date set when it is created, and Backstage will fail discovery silently or noisily once it lapses. Record the expiry date of each token, set a rotation schedule ahead of it, and confirm with the Azure DevOps administrators how long tokens may live under your organization's policy. Prefer a service principal or managed identity where Azure DevOps Services supports it, so rotation does not depend on one person's account. Approval: the Azure DevOps organization owner and the identity team.
Restricted repository and path scope
Limit discovery to the repositories and folders that the catalog is meant to cover, using the location and filter settings of the Azure DevOps catalog provider. Without these limits, Backstage will read every repository the credential can see, including archived or sensitive code. Test the filter with a sample of repositories before enabling it for the full organization, and record which paths are excluded. Approval: the catalog owner and the owner of each Azure DevOps project.
Approved network path for discovery
Route calls from the Backstage backend to Azure DevOps Services or Azure DevOps Server through an approved egress path, such as a fixed outbound proxy or a private connection to the on-premises server. This keeps the traffic visible to network security controls and avoids opening the Azure DevOps endpoint to unrelated hosts. Confirm the allowed host names and certificate trust with the network team before go-live, and document any custom certificate authority the backend needs. Approval: the network security team.
Failed authentication monitoring
Watch backend logs for repeated authentication or authorization failures from the Azure DevOps reader, since they can signal an expired token, a revoked service principal, or a credential being tested by someone else. Set an alert on those errors and assign an owner who responds to it. Also review which identity the failures came from after each rotation. Approval: the operations team that runs Backstage, with the security team defining the alert.
Testing discovery before turning it on for every repository
Run discovery against a sandbox first. Create a sandbox Azure DevOps project with a small set of repositories, and place a few catalog-info.yaml files in them that cover the cases you expect in production: a service with a clear owner, a component that belongs to a system, and one file with a deliberately missing field. Point the Azure DevOps discovery settings at only that project, then run discovery and keep the log of every location Backstage reads. The log is the first evidence you need. If a location you expected does not appear, the problem is in the provider configuration, the credential scope or the path pattern, and you should resolve it before any other check. Confirm the exact provider settings, scheduling options and log output against the Backstage catalog documentation for your version, since these details change between releases.
Review what the catalog actually created. For each entity produced from the sandbox, check the spec.owner, spec.lifecycle and spec.system fields, and confirm the entity kind and namespace match what you intended. An owner that resolves to nothing, or a lifecycle value your governance team does not recognize, is a defect in the descriptor template, not in the portal. Then delete one catalog file from a sandbox repository and run discovery again. Decide in advance whether the entity should be removed or marked as an orphan, and verify that Backstage does what your team expects. Record the expected entity count for each Azure DevOps project before the first production run. Later counts that drift from that baseline make new or removed repositories visible instead of silent.
Stop the rollout on partial reads. If a run fails for some repositories, or the log shows fewer locations than the baseline, halt the rollout for that project. The tempting fix is to widen the personal access token, service principal or managed identity to read more projects, because that makes the errors disappear. Doing so hides a scoping mistake and gives the portal access it does not need. Instead, find the cause, such as an expired token, a missing repository permission or a path pattern that does not match, correct it within the original scope, and rerun the sandbox test. Only expand to the next project after a clean run that matches the recorded baseline.
Why discovery returns no entities or fails to authenticate
This table lists the failures teams hit most when Backstage discovery against Azure DevOps returns nothing or cannot authenticate. Work down the rows in order, since the first check in each row rules out the most likely cause before you change credentials or network settings. Exact log wording varies by Backstage release, so confirm the messages against your own backend logs.
| Symptom or failure | Likely cause | First check | Fix |
|---|---|---|---|
| PAT rejected or expired | The personal access token has expired, was revoked, or belongs to a user who has left the organization. | Confirm the token's expiry and status in Azure DevOps user settings, then test it with a direct API call from the backend host. | Issue a new token with read scope on Code, store it in your secret manager, and set a calendar reminder before expiry. |
| Service principal sees no repositories | The service principal or its group lacks read access to the projects and repositories that hold catalog files. | Check the identity's permissions on each project and repository in the Azure DevOps security settings, not only at organization level. | Grant read access on the target projects, then rerun discovery and confirm the repositories appear in the backend logs. |
| Discovery runs but finds zero entities | The host entry in the integration config does not match the host in the discovery URL, so the integration is not applied. | Compare the host value in the Azure DevOps integration config with the host in your discovery location, character for character. | Align the host value with the URL used in discovery, including any differences between dev.azure.com and a custom Azure DevOps Server host name. |
| TLS or certificate error on Azure DevOps Server | The backend does not trust the certificate chain of the on-premises server, often because an internal certificate authority is missing. | Fetch the server's certificate chain from the backend host and verify it against the trust store the Node.js process uses. | Add the internal root or intermediate certificate to the trust configuration for the backend runtime, then restart and retest. |
| Connection timeout or refused from the backend | Network policy, a firewall rule, or a proxy blocks outbound traffic from the backend pod or host to Azure DevOps. | Run a basic connectivity test from the same container or host that runs the backend, not from a laptop. | Open the required outbound route or configure the proxy for the backend, and document the rule for your network team. |
| Catalog file not found in discovered repositories | The descriptor sits in a branch or path that the discovery pattern does not scan, such as a non-default branch or a different file name. | Check the configured catalog path pattern and confirm the file exists on the default branch at that exact path. | Adjust the path pattern or move the descriptor to the scanned location, then rerun discovery and check the processing logs. |
| Entities appear, then fail validation | The descriptor has a missing required field, an invalid name, or a malformed YAML structure, so the processor rejects it. | Read the validation error for the file in the backend logs and validate the YAML syntax and required keys locally. | Correct the descriptor, commit the change, and confirm the entity is accepted on the next refresh. |
| Errors appear only after a Backstage upgrade | A release changed log text or behavior, so existing runbooks no longer match the messages the backend prints. | Search your current logs for the entity or repository name rather than relying on a fixed error string from older guides. | Confirm log message text against the release you run, and update your troubleshooting notes after each upgrade. |
Questions teams ask before connecting Azure DevOps
How much effort does a Backstage and Azure DevOps integration take?
The effort depends mainly on how many Azure DevOps organizations are in scope, how many repositories hold catalog files, which credential model you choose, and whether the work must run on Azure DevOps Server inside your own network. A single organization with a modest number of repositories and a service principal or managed identity is a small configuration task. Several organizations, a large repository count, or on-premises constraints add discovery testing, credential handling and approval steps. Org data from your identity directory, if you also want users and groups loaded, is a separate workstream that adds more effort. Ask any partner to size the work from a written list of organizations, repositories and credential choices, and to state which items are included in the fixed scope.
How long does the integration usually take to deliver?
The schedule is set by approvals and access more often than by configuration work. The main drivers are how quickly your Azure DevOps administrators can create the identity and grant read access, how long network and firewall changes take for a self-hosted Azure DevOps Server, and how many rounds of catalog discovery testing your repositories need before the team accepts the results. Each additional organization or credential type extends testing. Ask for a timeline in the written scope that lists the dependencies on your side, so the schedule does not depend on undocumented steps. No duration is assumed here.
What must our internal team provide before the work starts?
Plan for four inputs. First, an Azure DevOps administrator who can create the chosen identity and grant it read access to the target organizations and projects. Second, a secret store approved by your security team, where the personal access token, service principal secret or other credential will be kept instead of plain configuration files. Third, network approvals that let the Backstage backend reach Azure DevOps Services or your on-premises Azure DevOps Server endpoints. Fourth, a test project containing sample catalog files, so discovery can be verified without touching production repositories. Confirm each item with your own administrators before the scope is signed.
Can our team connect Backstage to Azure DevOps without outside help?
A team with Backstage experience and Azure DevOps administration skills can often complete a single-organization setup alone, using the official Backstage documentation for the integration. Outside help is usually requested in a few predictable situations: several organizations sharing one Backstage instance, a self-hosted Azure DevOps Server with certificate or proxy complications, the need to combine discovery with identity-based sign-in, or a deadline that leaves no room for trial and error. Review the authentication and integration documentation first, then decide which parts your team can own. Ask any partner to state which parts it will do and which remain with your staff.
How are costs formed under a fixed-scope agreement?
Under a fixed-scope agreement, the quote follows from a written scope listing the organizations, repositories, credential models, environments and deliverables in the work. The main cost components are planning and design, configuration and testing across environments, documentation and handover to your operators. Cost rises with each added organization, each on-premises or network dependency, and each rework cycle caused by unclear requirements. Some items recur after delivery, such as ongoing support or upgrades under a retainer, and those should be quoted separately from the one-time build. Ask for the quote to show one-time and recurring items, the assumptions behind them, and what changes trigger a scope revision.
Does Backstage itself carry a license fee?
No. Backstage is an open source framework released under the Apache License 2.0 (SPDX: Apache-2.0), and the project itself offers no paid edition. Your costs come from the infrastructure you run it on, the people who build and operate it, and any services you choose to buy, such as implementation or support. Confirm the license text and any third-party plugin licenses you intend to use, because individual plugins are maintained separately and carry their own terms. Your legal or procurement team should review those terms as part of the plugin selection process.
What should engineers check when Azure DevOps catalog discovery returns nothing?
Start by confirming the credential has read access to the exact organization, project and repository that holds the catalog file, because a token or identity scoped too narrowly returns empty results without a clear error. Next, check that the discovery configuration targets the correct organization URL and that the catalog file name and location match the pattern the provider expects. For Azure DevOps Server, confirm that the Backstage backend can reach the endpoint from the host where it runs, not just from a developer laptop. Finally, check the backend logs for authentication or network errors. Record each finding so the same checklist can be reused for the next organization.
How DeployOpen scopes the Azure DevOps connection
DeployOpen plans, implements, documents and supports self-hosted Backstage inside your own infrastructure, including the Azure DevOps connection for catalog discovery and sign-in. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory which Azure DevOps Services organizations or Azure DevOps Server instances hold catalog-info files and must be discovered
- Record the credential option chosen for each organization, with its owner, rotation approach and permission boundary
- Confirm which on-premises authentication limits apply, and the written scope and deliverables that follow from them
How we build
- Configure the Azure DevOps integration and discovery provider in your Backstage backend, using the agreed credential type per organization
- Set catalog location paths and filters so only intended repositories and branches produce catalog entities
- Test discovery and ingestion in a non-production Backstage instance before any change reaches the production catalog
How we hand over
- Deliver the configuration, credential runbook and a record of which organizations and repositories are in scope
- Document how to rotate tokens or service principal secrets and what breaks if a credential expires
- Walk your platform and identity teams through verifying discovery results and troubleshooting catalog errors
How we support
- Support ongoing operation of the integration as a retainer, including reviewing credential expiry and permission changes
- Plan and test Backstage version upgrades against the Azure DevOps integration before they reach production
- Revisit the scope when new Azure DevOps organizations, projects or repositories need to join the catalog
