Configure sdlc.yaml

This guide walks through configuring sdlc.yaml for your repository. LaneSync reads this file from GitHub on every stage-details request.

Before you start

Repo setup wizard completed (or sdlc.yaml exists at repo root)
You know your GitHub Actions job names (they must match required_checks exactly)
You have decided: trunk-based or release-branch workflow

Base structure

version: v1
name: my-app

stages:
  planning: { ... }
  development: { ... }
  testing: { ... }
  evidencing: { ... }
  deployment: { ... }

Stage-by-stage configuration

Planning

planning:
  require_milestone: true
  require_issues_assigned: true

Ensures every release has a milestone and assigned owners before development.

Development

development:
  branch: main
  deploy_target: dev
  required_checks:
    - CI — Build & Test

required_checks lists GitHub Actions check names that must pass on main. Only failures on these checks block the stage.

Testing

Release-branch
Trunk-based

testing:
  branch_pattern: "release/*"
  deploy_target: staging
  required_checks:
    - CI — Build & Test

Create release/v1.0.0 after development. Gates evaluate the release branch.

Omit or adjust branch_pattern during wizard setup for trunk-based flow. Required checks run on main.

Evidencing

evidencing:
  required_artifacts:
    - test-results
  required_reviewers:
    min_approvals: 1
    teams:
      - engineering-leads

teams maps to GitHub teams that can approve the evidence PR.

Deployment

deployment:
  target: production
  promotion: manual
  requires_evidence_approval: true

Production promotion stays manual until you integrate automated deploy workflows.

Staging environment (`hasStaging`)

The repo wizard hasStaging toggle controls whether your pipeline includes a staging environment between development and production. When enabled (Dev → Staging → Prod), bootstrap generates:

deploy_target: staging under stages.testing
Staging deploy workflow templates (when you do not already have deployment workflows)
Additional evidencing artifacts: test-results-staging alongside sdlc-evidence

When disabled (Dev → Prod), the testing stage omits the staging deploy target and staging-specific artifacts. Required checks still run — on the release branch or development branch depending on release model.

Enable staging when QA validates releases in a pre-production environment before evidencing and production promotion.

Release model (`releaseModel`)

The wizard releaseModel field sets how code moves from development to testing.

Trunk (`trunk`)
Release-branch (`release-branch`)

Development and testing both target the development branch (usually main). There is no separate release branch to cut.In sdlc.yaml, stages.testing.branch_pattern equals the development branch name — for example main.Best for: Continuous delivery teams that ship directly from trunk.

After development completes, you cut a release branch (e.g. release/v1.2.0) from the development branch. Testing gates evaluate checks on that branch.In sdlc.yaml, stages.testing.branch_pattern uses your release prefix — for example release/** when the wizard prefix is release/.Use Cut release branch in the milestone dashboard to create the branch. See Milestone details — Branch Actions.

SDLC Enforce is always required regardless of release model. Only checks listed in required_checks block a stage when they fail.

Apply changes

Edit sdlc.yaml in a branch
Open a PR and merge to the default branch
LaneSync webhook fires → re-parses checks → updates rulesets → re-syncs milestones

After renaming a CI job, update required_checks in the same PR as the workflow change to avoid phantom BLOCKING badges.

Validate configuration

Check	How
Check names match CI	Compare with `.github/workflows/*.yml` job `name:` fields
Rulesets updated	GitHub → Repository → Rulesets
Stage details reflect file	Dashboard → Milestone → Stage details (live read, 60s cache)

Full schema

See sdlc.yaml schema reference for every field and constraint.

Get Started

Concepts

Guides

Dashboard

Reference

Enterprise

Configure sdlc.yaml

Before you start

Base structure

Stage-by-stage configuration

Staging environment (`hasStaging`)

Release model (`releaseModel`)

Apply changes

Validate configuration

Full schema

​Before you start

​Base structure

​Stage-by-stage configuration

​Staging environment (hasStaging)

​Release model (releaseModel)

​Apply changes

​Validate configuration

​Full schema

Before you start

Base structure

Stage-by-stage configuration

Staging environment (`hasStaging`)

Release model (`releaseModel`)

Apply changes

Validate configuration

Full schema