# Help Wanted: Intent based pipelines

Drawing a software delivery pipeline is a task that takes a couple of developers 30 minutes and a whiteboard.

We start our build, we do some testing, try it out in staging and.. when we’re happy.. publish it to production. Going from there to a working pipeline that’s modeled in the way that you want either requires a large framework investment that’s likely company-specific (Amazon, Google), using a SaaS provider (CloudBees, CircleCI), or writing a bunch of Kubernetes YAML / Bash scripts.

At the [Interoperability SIG](https://github.com/cdfoundation/sig-interoperability/), we’ve been discussing what it might look like to have a simplified [DSL](https://en.wikipedia.org/wiki/Domain-specific_language) for expressing the outcomes of a pipeline, without getting so tied into the mechanisms of telling the system how to do it. This is an illustrative (but not particularly battle-hardened) example:

meta:
  # Channel which will get updates on deploys. One message for each release and
  # Information in the thread as it progresses through the pipeline.
  slackChannel: myapp-deploys

  # Who to complain to when this breaks.
  owners: your-ldap-or-equivalent-group-here

build:
  # Explicitly not setting up a jenkins instance. Framework should do this, if necessary.
  type: docker
  # ...or...
  # command: mvn package

deploy:
  default:  # These apply to all stages below, unless they're overridden
    cores: 100m
    memory: 300Mb
    ramp:
      # deploy to 1% then 10% then 100% as a rollout strategy. There will be
      # a few options available.
      rolloutStrategy: ONE_TEN_ALL
      bakeTime: 5m
  dev:
    rollout:
      regions: dev-west-1a
  staging:
    rollout:
      regions: dev-west-1a
  prod:
    rollout:
      regions: prod-west-1a, prod-west-1b, prod-west-2a, prod-west-2c
      # Starting from 1, deploy to 2x the regions of the last deploy, so 1,2,4,8,16.
      strategy: GEOMETRIC
    approvals:
      - metricsValidator:
          promql: sum(increase(failure[5m])) > 5
          onResults: rollback

Something like the above would allow us to simplify the expression of what we want the shape of our pipeline to be, but without having to become experts in [Tekton](https://tekton.dev/) or [Argo](https://argoproj.github.io/) or any of the other great tools for accomplishing this. This will hopefully allow more developers to engage with CI/CD pipelines and have a more active role in the quality of their software.

## Join the Conversation
If this sounds like something you're interested in, we'd love to discuss it with you during one of [our regular, open-to-anyone meetings](https://github.com/cdfoundation/sig-interoperability/) or give `#sig-interoperability` a ping in [slack](https://join.slack.com/t/cdeliveryfdn/shared_invite/zt-nwc0jjd0-G65oEpv5ynFfPD5oOX5Ogg).