Formal CD primitive and mechanism

[lispyclouds]

Bob should be able to deliver code in a de-coupled way akin to fetching resource or uploading artifacts.

[TimoKramer]

Since bob is CI and CD is kind of messy we think it could be cool to use an artifact-store that triggers something like Spinnaker, ArgoCD or Tekton. Spinnaker supports different cloud providers and ArgoCD and Tekton support only Kubernetes. Spinnaker could be triggered by webhook.

[aldosolorzano]

How does the CD currently works? This means that similar to the UI and artifact-store CD could be something plugable to bob via webhook and also provide an opinionated service that could do it?

[lispyclouds]

There is no formally defined way to do CD as of now. Like you said an artifact-store could be implemented to do CD when given a container image for example. But my thoughts were to formally have a CD mechanism:

• Like artifact and resource we could have a new primitive deployment.
• It has a corresponding service which abstracts away the actual thing like the ones mentioned by @TimoKramer above or things like AWS CodeDeploy.
• The service has a defined contract with Bob that:
  • Takes in the thing to be deployed, like a container image or k8s manifest etc
  • As a response, offers Bob a streaming endpoint which relays the deployment events in a specific format back and Bob can keep a track of it.

[lispyclouds]

Is a Deployment an Artifact too? Food for thought 🤔

[aldosolorzano]

If I understood correctly, an option is to have a new primitive Deployment which is triggered after the artifact is created and stored in the plugged service. Then, if a deployment is created, it means that it will read the artifact from the stored service and then send it to the CD service and work as a lifecycle tracker. That means that bob depends on an external service to do the deployment itself, right?

[lispyclouds]

Exactly. A step can have maybe a key "deploys" which points to a dir with manifests or something and ships it off the the deployer to do the real thing. Like we have artifact stores and resource providers we need another service abstracting the things like AWS CodeDeploy or ArgoCD etc. And that has the api contract with Bob like I described. It's all my thoughts, more opinions most welcome!

[aldosolorzano]

I'm trying to visualize it

artifact <- bob -> deployment-service -> argo/aws/tekton 

Somethings I like about it:

• It follow the bob philosophy of only owning things that are actually needed.
• Freedom of choice about which cd service to use

Questions:

1. does this means that the deployment-service is something bob-cd has as an opinionated version, and if the user decides to do it their own way they could do it?
2. Can we support any CD service, i mean probably we need to write the weebhook in the deployment-service but in theory works right?
3. More philosophical question (and probably because I don't have much context) as I user if I need to also plug a different service to be able to deploy, why would I want to use bob if I could use the other service (unless it's only CD and not CI)?

[lispyclouds]

Yes essentially a step in Bob, given a resource and a command may produce an artifact or a deployment in this new world.

does this means that the deployment-service is something bob-cd has as an opinionated version, and if the user decides to do it their own way they could do it?

Like we have resource-git and artifact-local more as like a reference implementations rather than opinionated ones, we can have one implementing the deployment spec based on something like Argo/Spinnaker etc. That implies we should have the deployment spec first. 😅

Can we support any CD service, i mean probably we need to write the weebhook in the deployment-service but in theory works right?

yes, also i dont think it needs webhook, Bob should call the service with the payload like it does for artifact stores in a step.

More philosophical question (and probably because I don't have much context) as I user if I need to also plug a different service to be able to deploy, why would I want to use bob if I could use the other service (unless it's only CD and not CI)?

Bob is more of a free from orchestration platform, sort of geared towards CI but you should be able to express your needs on it freely; it gives you building primitives rather than a finished product, much like Clojure. That also implies that its not a Getting started quickly thing but some assembly required, like Clojure again; geared towards special needs teams like platform teams and/or people building CI/CD/orchestration tooling. Bob is aiming to simplify this complexity at the core. Have a look at the talk, I go a bit into it 😄

[lispyclouds]

specially about:

why would I want to use bob if I could use the other service (unless it's only CD and not CI)?

once someone chooses something like Argo/Tekton etc you need to abide by its opinions like k8s. Bob aims to be a decoupling mechanism between all of these established but opinionated tooling allowing you to plug and play like legos.

[aldosolorzano]

Makes sense, it also provides the freedom to try different CD or have multiple running, in case of deprecating one of them or wanting extra redundancy. I will spend some time understanding better the existing primitives Resource, Artifact, Pipeline and come with some ideas.

Is a Deployment an Artifact too?

I would ask,

• all Artifacts are deployable?
• an Artifact is a possible final state, for example using bob only for CI?
• seems that a Deployment could depend on many Artifacts? meaning, deploying many artifacts