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

# Project roll-ups

> Group milestones across microservices into CEO-level release projects with aggregate deploy status.

Large organizations ship releases that span **multiple repositories**. LaneSync **project roll-ups** aggregate milestone status across microservices into a single executive view.

## Use case

| Without roll-ups                             | With roll-ups                         |
| -------------------------------------------- | ------------------------------------- |
| Check 12 repo dashboards for `v2.4.0` status | One project view: `Platform v2.4.0`   |
| Manual spreadsheet for release readiness     | Aggregate deploy status per service   |
| Unclear which service blocks the release     | Blocking repos highlighted in roll-up |

## Concepts

```mermaid theme={null}
flowchart TB
  project[Release Project — Platform v2.4.0]
  m1[api-gateway v2.4.0]
  m2[auth-service v2.4.0]
  m3[billing-worker v2.4.0]

  project --> m1
  project --> m2
  project --> m3
```

| Entity               | Description                                                   |
| -------------------- | ------------------------------------------------------------- |
| **Project**          | Named release spanning multiple repos (e.g. quarterly launch) |
| **Linked milestone** | A repo milestone version attached to the project              |
| **Aggregate status** | Worst-case or summary stage across linked milestones          |

## Create a project

<Steps>
  <Step title="Open Projects">
    In [lanesync.dev](https://lanesync.dev), navigate to **Projects** in the sidebar.
  </Step>

  <Step title="Create release project">
    Click **New project**. Enter name (e.g. `Platform v2.4.0`) and optional target date.
  </Step>

  <Step title="Link milestones">
    Add milestones from each microservice repository. Each linked milestone should use a consistent version label (e.g. `v2.4.0`).
  </Step>

  <Step title="Monitor aggregate status">
    The project dashboard shows per-service stage pipelines and highlights blocking services.
  </Step>
</Steps>

## API

Projects are managed via `/api/projects`:

| Method | Path                                        | Description      |
| ------ | ------------------------------------------- | ---------------- |
| GET    | `/api/projects`                             | List projects    |
| POST   | `/api/projects`                             | Create project   |
| PATCH  | `/api/projects/:id`                         | Update project   |
| POST   | `/api/projects/:id/milestones`              | Link milestone   |
| DELETE | `/api/projects/:id/milestones/:milestoneId` | Unlink milestone |

Session authentication required. See [API Reference](/api-reference/introduction).

## Best practices

<AccordionGroup>
  <Accordion title="Align version labels">
    Use the same semver across services (`v2.4.0`) so stakeholders recognize one release train.
  </Accordion>

  <Accordion title="Define a critical path">
    Mark blocking services in your release process. Roll-ups surface which repo is furthest behind.
  </Accordion>

  <Accordion title="Pair with evidence approval">
    Each service still completes its own EVIDENCING gate. Roll-ups do not bypass per-repo enforcement.
  </Accordion>
</AccordionGroup>

## Limitations

* Roll-ups are **visibility and coordination** — enforcement remains per-repository via `sdlc.yaml`
* A project cannot advance a milestone on your behalf; teams still merge, test, and approve per repo

## Related

* [Dashboard overview](/dashboard/overview) — org-wide milestone view
* [Your first release](/guides/first-release) — single-repo walkthrough