CD Foundation

Contributed by Justin Abrahms, eBay

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, we’ve been discussing what it might look like to have a simplified DSL 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 or Argo 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 or give #sig-interoperability a ping in slack.