iterative / iterative/gto

Feature Request: Deployment Stage DAG Enforcement

Open
#321 3 comments 1 reaction 0 assignees View on GitHub
enhancement stages studio
Dominant language
Python
Stars
162
Forks
18
PR merge metrics
No merged PRs in 30d

Description

I'm interested in enforcing that model versions are assigned to "lower" deployment environments (closer to dev) before they are allowed to be assigned to "higher" environments (closer to prod). I've drafted out an example below, and was curious if this feature would align w/ the goals for GTO?

```mermaid
graph LR;
dev-->qa;
qa-->stage;
stage-->prod;
hot-stage-->prod;
```

For instance, to enforce the promotion DAG above, maybe an extension of the existing `STAGES` field in the `.gto` file:

```yaml
STAGES:
- dev
- qa:
promotes_from:
- dev
- stage:
promotes_from:
- qa
- hot-stage
- prod:
promotes_from:
- stage
- hot-stage

```

Then during normal use you'd see:
```bash
gto register hello-world
gto assign hello-world --version v0.0.1 --stage dev
gto assign hello-world --version v0.0.1 --stage qa

# some commits and dev work
gto register hello-world --bump-patch

# this should fail, as it should enforce assignment to `dev` before assigning to `qa`
gto assign hello-world --version v0.0.2 --stage qa

# ?? maybe allow `--force` to override DAG rules ??
gto assign hello-world --version v0.0.2 --stage qa --force
```

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.