How do I connect CI/CD, cloud, and observability into one developer portal?

To connect CI/CD, cloud, and observability into one developer portal, think of the portal as a single front door that aggregates tooling, automates workflows, and exposes operational context for every service.

1) Define the portal’s purpose

Your portal should answer, for any service or team:

• What is it? service metadata, owners, docs, dependencies
• How is it built and deployed? CI/CD pipelines, environments, release status
• Where is it running? cloud resources, clusters, accounts, regions
• How is it behaving? logs, metrics, traces, alerts, SLOs
• What should I do next? deploy, rollback, create runbook, open incident, view dashboard

2) Use a service catalog as the core

A developer portal usually starts with a service catalog that stores and displays:

• service name
• owners and on-call
• repo links
• CI/CD pipeline links
• cloud/runtime info
• observability dashboards
• runbooks and docs
• dependencies and APIs
• lifecycle state

Popular catalog/portal platforms:

• Backstage is the most common open-source option
• Port, Cortex, OpsLevel, Split’s developer portal offerings, etc.

3) Integrate CI/CD

Connect your CI/CD system so the portal can show build and deployment status, and trigger actions.

Examples:

• GitHub Actions
• GitLab CI
• Jenkins
• CircleCI
• Azure DevOps
• Argo CD / Flux for GitOps

What to expose in the portal:

• latest build result
• deployment history
• environment status
• promotion approvals
• rollback button or link
• change logs / release notes

How:

• Use webhooks or APIs from CI/CD tools
• Map pipeline runs to services and environments
• Store deployment events in the catalog or event stream

4) Integrate cloud infrastructure

Connect cloud providers and orchestration platforms so the portal knows where services run.

Examples:

• AWS
• GCP
• Azure
• Kubernetes
• Terraform / Pulumi / Crossplane

What to show:

• clusters, namespaces, workloads
• cloud accounts/projects/subscriptions
• regions and environments
• databases, queues, buckets, secrets references
• resource ownership and cost data

How:

• Pull resource inventory from cloud APIs
• Sync Kubernetes manifests and labels
• Ingest IaC metadata from Terraform state/plans
• Associate cloud resources with services via tags/annotations/labels

5) Integrate observability

Bring in monitoring and troubleshooting context so the portal becomes operationally useful.

Examples:

• Datadog
• Grafana / Prometheus / Loki / Tempo
• New Relic
• Dynatrace
• Splunk
• Elastic
• OpenTelemetry backends

What to surface:

• service dashboards
• error rates, latency, saturation
• logs and traces
• active alerts/incidents
• SLO compliance
• recent anomalies
• runbooks

How:

• Link each service to dashboards and alerts
• Use service metadata to auto-route to the right telemetry
• Embed query links or panels directly in the portal

6) Normalize everything with a common service model

The main challenge is not the integrations themselves; it’s connecting data to the same service identity.

Use a consistent model:

• service
• owner
• repo
• environment
• deployment
• cluster
• dashboard
• alert
• runbook

Best practices:

• use tags/labels/annotations everywhere
• enforce naming conventions
• generate metadata from code where possible
• keep one source of truth for ownership

7) Make the portal actionable

Don’t just display links. Add workflows:

• create a new service from a template
• deploy to an environment
• view deployment approval status
• restart a workload
• create an incident ticket
• acknowledge an alert
• open runbook from an alert
• generate docs from templates

This turns the portal from a directory into an operations hub.

8) Recommended architecture

A simple pattern is:

• Portal UI: developer-facing web app
• Catalog backend: service metadata + relations
• Integrations layer: plugins/connectors for Git, CI/CD, cloud, observability
• Auth layer: SSO via Okta/Auth0/Azure AD/Google
• Data sources: GitHub/GitLab, Kubernetes, cloud APIs, telemetry platforms
• Event ingestion: webhooks + scheduled sync jobs
• Automation: actions via APIs, chatops, or GitOps

9) Example with Backstage

A common implementation looks like this:

• Backstage catalog stores services and ownership
• TechDocs hosts docs
• Scaffolder creates new services from templates
• CI/CD plugin shows pipeline and deployment status
• Kubernetes plugin shows runtime resources
• Datadog/Grafana plugin shows dashboards and alerts
• SLO plugin shows service health and error budgets

You annotate services in YAML, for example:

• repo URL
• owner
• system
• dashboard links
• Kubernetes namespace
• pipeline links

10) Rollout approach

Start small:

1. Pick 5–10 critical services
2. Define a minimal service schema
3. Connect repo + CI/CD first
4. Add cloud runtime visibility
5. Add dashboards/alerts
6. Add self-service actions
7. Expand adoption with templates and governance

11) Key pitfalls to avoid

• Too many tools, no common service identity
• Manual metadata entry with no enforcement
• Portal becomes a static wiki
• No ownership or freshness guarantees
• Over-integrating before proving value
• No role-based access control

12) A practical target state

A developer opens one portal page and sees:

• service overview
• owner/on-call
• repo and docs
• latest build/deploy
• cloud environment and runtime
• dashboards, logs, traces
• open alerts and recent incidents
• deploy/rollback/self-service actions

If you want, I can also give you:

1. a reference architecture diagram,
2. a Backstage-based implementation plan, or
3. a minimal YAML schema for linking CI/CD, cloud, and observability.