> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lanesync.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Configure sdlc.yaml

> Customize stage gates, required checks, artifacts, and reviewers in sdlc.yaml for your repository.

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

```yaml theme={null}
version: v1
name: my-app

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

## Stage-by-stage configuration

<Steps>
  <Step title="Planning">
    ```yaml theme={null}
    planning:
      require_milestone: true
      require_issues_assigned: true
    ```

    Ensures every release has a milestone and assigned owners before development.
  </Step>

  <Step title="Development">
    ```yaml theme={null}
    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.
  </Step>

  <Step title="Testing">
    <Tabs>
      <Tab title="Release-branch">
        ```yaml theme={null}
        testing:
          branch_pattern: "release/*"
          deploy_target: staging
          required_checks:
            - CI — Build & Test
        ```

        Create `release/v1.0.0` after development. Gates evaluate the release branch.
      </Tab>

      <Tab title="Trunk-based">
        Omit or adjust `branch_pattern` during wizard setup for trunk-based flow. Required checks run on `main`.
      </Tab>
    </Tabs>
  </Step>

  <Step title="Evidencing">
    ```yaml theme={null}
    evidencing:
      required_artifacts:
        - test-results
      required_reviewers:
        min_approvals: 1
        teams:
          - engineering-leads
    ```

    `teams` maps to GitHub teams that can approve the evidence PR.
  </Step>

  <Step title="Deployment">
    ```yaml theme={null}
    deployment:
      target: production
      promotion: manual
      requires_evidence_approval: true
    ```

    Production promotion stays manual until you integrate automated deploy workflows.
  </Step>
</Steps>

## 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.

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

## Release model (`releaseModel`)

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

<Tabs>
  <Tab title="Trunk (`trunk`)">
    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.
  </Tab>

  <Tab title="Release-branch (`release-branch`)">
    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](/dashboard/milestone-details#branch-actions).
  </Tab>
</Tabs>

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

## Apply changes

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

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

## 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](/reference/sdlc-yaml-schema) for every field and constraint.