DocsCode and infrastructure

Systems and shared code

See how your repositories fit together, which version of shared code each place uses, and upgrade it everywhere with one pull request per repository.

Many companies keep common code in shared repositories (Terraform modules, reusable workflows, base images, Helm charts, internal libraries) and use it from many services, or keep several services in one monorepo. Systems reads all of that from the repositories’ own files on every check. There’s nothing to set up.

Systems: services, shared repositories and how they depend on each other.
The map: systems, services and the shared code they use.

Shared code and versions

The Shared code tab lists every module source, workflow uses:, Dockerfile FROM, Helm dependency, Kustomize base and package dependency (npm, Go, Python) that points at one of your repositories or images: which version each place uses, and the latest version.

Places that follow a branch (@main) instead of a version are called out: whatever merges there reaches them untested.

Shared code: each shared thing with its latest version and where it is used.
Shared code: who uses what, at which version, and Upgrade.

Upgrade everywhere

Upgrade opens one pull request per repository that changes only the lines pinning the old version. Nothing changes until someone merges it, and each repository’s own checks run first.

Weekly automatic upgrades

Under Shared code → Automatic upgrades, pick a day and hour. Once a week OpsNexa Online opens the upgrade pull requests nobody has opened yet: minor versions only unless you allow majors, places that follow a branch only if you ask, and at most a set number per run. Nothing merges by itself. Run now does the same at once.

More views

  • Services: monorepos split into services (one per folder that builds or deploys something), each with its own owners, findings, cost and environments.
  • Deployments: Argo CD and Flux followed to the images they deploy, so you see the version in each environment side by side. Apps hosted by OpsNexa Online count too.
  • Runtime: what talks to what, from Docker Compose files and Kubernetes manifests, with a warning when several services share one database.
  • Owners come from CODEOWNERS and Backstage catalog-info.yaml.

Grouping

Repositories are grouped into systems automatically: by spec.system in Backstage files when you have them, shared and deployment repositories under Platform, and otherwise by a common name prefix (billing-api, billing-worker). Use New system to group them yourself.

Something unclear or missing? Tell us, or press the ? at the top of OpsNexa Online for the guide and tours inside the product.