Harness Service Onboarding

Harness Service Onboarding

Purpose

Guide the complete end-to-end onboarding of a new service onto Harness: from creating the service entity to wiring up environments, infrastructure definitions, connectors, monitored services, and the first pipeline run.

---

Input Contract

| Input | Source | Required | |---|---|---| | Pipeline YAML / service name | s04 (workflow_context.artifacts) | Yes | | Repository URL, container registry | s01 or user | Yes | | Kubernetes cluster info | s06 output or user | Yes | | Harness org/project identifiers | CLAUDE.md | Yes | | Delegate selector | s06 output | No | | Observability tool choice | s02 taste or s01 | No |

Output Contract

| Output | Destination | Format | |---|---|---| | Service definition YAML | .commandcode/artifacts/service-.yaml | YAML | | Environment YAML per tier | .commandcode/artifacts/env-.yaml | YAML | | Infrastructure definition YAML | .commandcode/artifacts/infra--.yaml | YAML | | Connector configs | .commandcode/artifacts/connectors.yaml | YAML | | Onboarding hand-off document | User + s06 feed | Markdown | | Service context (for s06, s07, s08, s10, s15) | workflow_context.artifacts | YAML object |

---

Prerequisites

Gather before proceeding:

• [ ] Service name, language/runtime, and repository URL
• [ ] Container registry location (ECR, GCR, DockerHub, ACR)
• [ ] Kubernetes cluster and namespace (or other target infra)
• [ ] Harness Organization and Project identifiers
• [ ] Cloud provider credentials (for connector setup)
• [ ] Observability tool (Prometheus, Datadog, etc.) if CV is needed

---

Onboarding Checklist (run in order)

[ ] 1. Create Connector(s)
[ ] 2. Create Service Definition
[ ] 3. Create Environment(s)
[ ] 4. Create Infrastructure Definition(s)
[ ] 5. Scope Delegate to Namespace
[ ] 6. Create Monitored Service (if CV enabled)
[ ] 7. Create Pipeline (reference harness/01-pipeline-design)
[ ] 8. Create Input Set for each environment
[ ] 9. First dry-run validation
[ ] 10. Hand-off documentation

---

Step 1 — Connectors

Kubernetes Cluster Connector

connector:
  name:  K8s
  identifier: _k8s
  orgIdentifier: 
  projectIdentifier: 
  type: K8sCluster
  spec:
    credential:
      type: InheritFromDelegate
    delegateSelectors:
      - 

Docker Registry Connector

connector:
  name: 
  identifier: 
  type: DockerRegistry
  spec:
    dockerRegistryUrl: https://index.docker.io/v2/
    providerType: DockerHub
    auth:
      type: UsernamePassword
      spec:
        username: 
        passwordRef: docker_password_secret

GitHub Source Connector

connector:
  name: GitHub 
  identifier: github_
  type: Github
  spec:
    url: https://github.com/
    connectionType: Account
    authentication:
      type: Http
      spec:
        type: UsernameToken
        spec:
          username: 
          tokenRef: github_pat_secret
    apiAccess:
      type: Token
      spec:
        tokenRef: github_pat_secret
    delegateSelectors:
      - 

---

Step 2 — Service Definition

service:
  name: 
  identifier: 
  orgIdentifier: 
  projectIdentifier: 
  description: ""
  tags:
    team: 
    domain: 
    managed-by: hcprm
  serviceDefinition:
    type: Kubernetes
    spec:
      manifests:
        - manifest:
            identifier: k8s_manifests
            type: K8sManifest
            spec:
              store:
                type: Github
                spec:
                  connectorRef: github_
                  gitFetchType: Branch
                  branch: main
                  paths:
                    - k8s/
              valuesPaths:
                - k8s/values.yaml
              skipResourceVersioning: false
              enableDeclarativeRollback: true
      artifacts:
        primary:
          primaryArtifactRef: primary
          sources:
            - identifier: primary
              sourceType: DockerRegistry
              spec:
                connectorRef: 
                imagePath: 
                tag: 
      variables:
        - name: replicaCount
          type: String
          value: "2"
        - name: memoryLimit
          type: String
          value: "512Mi"
        - name: cpuLimit
          type: String
          value: "500m"

---

Step 3 — Environments

# Create one environment entity per tier
environment:
  name:   # e.g., staging
  identifier: 
  orgIdentifier: 
  projectIdentifier: 
  type: PreProduction  # or Production
  tags:
    managed-by: hcprm
  variables:
    - name: replicaCount
      type: String
      value: "1"   # override per-env
  overrides:
    manifests:
      - manifest:
          identifier: env_values
          type: Values
          spec:
            store:
              type: Github
              spec:
                connectorRef: github_
                gitFetchType: Branch
                branch: main
                paths:
                  - k8s/values-.yaml

---

Step 4 — Infrastructure Definition

infrastructureDefinition:
  name: --infra
  identifier: __infra
  orgIdentifier: 
  projectIdentifier: 
  environmentRef: 
  deploymentType: Kubernetes
  type: KubernetesDirect
  spec:
    connectorRef: _k8s
    namespace: 
    releaseName: release-
  allowSimultaneousDeployments: false

---

Step 5 — Delegate Scoping

Ensure the delegate has access to the target namespace:

# If using Harness Delegate Helm chart, apply RBAC:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: harness-delegate-role
  namespace: 
  labels:
    managed-by: hcprm
rules:
  - apiGroups: ["", "apps", "extensions", "batch"]
    resources: ["pods", "deployments", "services", "configmaps",
                "secrets", "replicasets", "jobs", "statefulsets"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: ["networking.k8s.io"]
    resources: ["ingresses"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: harness-delegate-binding
  namespace: 
subjects:
  - kind: ServiceAccount
    name: harness-delegate
    namespace: harness-delegate
roleRef:
  kind: Role
  name: harness-delegate-role
  apiGroup: rbac.authorization.k8s.io

Reference harness/03-delegate-management for full delegate setup.

---

Step 6 — Input Sets

Input sets capture environment-specific values, avoiding pipeline duplication.

inputSet:
  name:  Input Set
  identifier: _input_set
  orgIdentifier: 
  projectIdentifier: 
  pipelineIdentifier: _pipeline
  inputSetReferences: []
  pipeline:
    identifier: _pipeline
    variables:
      - name: imageTag
        value: latest
      - name: targetEnv
        value: 
    stages:
      - stage:
          identifier: Deploy_
          spec:
            environment:
              environmentRef: 
              infrastructureDefinitions:
                - identifier: __infra

---

Step 7 — Dry-Run Validation

Before first real deployment, run pipeline with skipDryRun: false:

1. Navigate to pipeline → Run → select input set
2. Enable "Dry Run" toggle (CD stage will generate manifests without applying)
3. Review generated manifest in execution logs
4. Confirm: correct image, namespace, resource limits, labels

---

Onboarding Hand-off Template

Generate and share this document with the service team:

## Harness Onboarding Summary — 

**Project**:  | **Org**: 

### Resources Created
| Resource | Identifier |
|---|---|
| Service |  |
| Environment (dev) | dev |
| Environment (staging) | staging |
| Infrastructure (dev) | _dev_infra |
| Infrastructure (staging) | _staging_infra |
| Pipeline | _pipeline |

### How to Deploy
1. Push to `main` branch → webhook trigger fires automatically
2. Or: Harness UI → Pipelines →  → Run → select input set

### Contacts
- SRE Owner: 
- Harness Admin: 
- Runbook: 

---

AI Agent Integration

Autonomy Level

| Aspect | Level | Description | |---|---|---| | Current | L2 | AI generates service/env/connector definitions from prompts | | Target | L3 | AI creates and configures services, human validates |

Harness AI Agent

Agent: Harness AI DevOps Agent Capabilities:

• Service creation via conversational prompts
• Environment definition generation
• Connector configuration
• Service dependency mapping

Human Gates

• Service definition approval
• Production environment creation

Fallback

When Harness AI is unavailable: Use static pipeline templates from s09 Template Library and manual YAML construction following Harness schema documentation.

---

Success Criteria

• [ ] All connectors tested and showing "Success"
• [ ] Service definition saved and visible in Harness UI
• [ ] Infrastructure definition linked to correct cluster/namespace
• [ ] Dry-run executed without errors
• [ ] First real deployment to dev completed successfully
• [ ] Hand-off document delivered to service team

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: dungnotnull
• Source: dungnotnull/hybrid-harness-chaos-process-prm
• License: MIT

Install and usage instructions live in the source repository linked above.