kohidave
commented
2 years ago Manifest Designs
We're thinking about other ways to design our manifest file and would love your thoughts:
Option 1️⃣
Simple Case: Syncing a single service from multiple branches.
# This is the contents of the .proton-ops.yaml file
service-sync:
main: # When a commit happens on this branch
sync:
# Sync the service-spec.yaml file on the main branch to the service instance daves-svc-beta
to: daves-svc-beta
prod: # When a commit happens on this branch
sync:
# Sync the service-spec.yaml file on the prod branch to the service instance daves-svc-prod
to: daves-svc-prodAdvanced Case: Syncing multiple services from multiple branches.
# This is the contents of the .proton-ops.yaml file
service-sync:
main: # When a commit happens on this branch
sync:
- to: daves-svc-beta
-
to: bob-svc-beta
spec: bob-svc/service-spec.yaml
depends-on: daves-svc-beta
publish:
to: prod
prod: # When a commit happens on this branch
sync:
- to: daves-svc-prod
-
to: bob-svc-prod
spec: bob-svc/service-spec.yaml
depends-on: daves-svc-prod
haakond
💕 Howdy ya'll! We (the Proton team) have started work on a feature we're pretty excited about (GitOps management of services #11 ) and wanted to get your feedback on how we're thinking about designing our manifest for Service Sync! 💕
What's Service Sync?
So one feature we've been really excited about for a while is enabling folks to sync their service specs directly from their git repos. Right now, service owners can set up a Pipeline that pulls a particular branch, packages up the code, and automatically updates the service spec file for a particular instance.
Service Sync, a new feature we're working on, let's folks store their spec files directly in their git repo. Proton will listen to your repo, and any time you update the spec file, automatically sync that change to a particular service instance.
How will it work?
The way we're thinking about this feature is you'll register your git repository with Proton (just like you do with Template Sync today), and then associate that repository with a Service.
Proton will then look for a special, magical file called the
.proton-ops(we'll probably come up with a better name) which will instruct Proton on what to sync where.What does the Proton Ops file look like?
So the
.proton-opsfile will contain all the information Proton needs to understand where a particular service spec is in your repository, and which service instance it should be synced to. Let's take a look at an example of a (very early, and very draft) version of this file:In the above example, we're using a branch per environment strategy. We map the
mainbranch to thedaves-svc-betaservice instance. Whenever we update the service spec on main, thedaves-svc-betaservice instance will be updated. Whenever we update the service spec on the prod branch, thedaves-svc-prodservice instance will be updated.Multiple Services per Repo
One possibility that we want to support is letting folks sync multiple services from one repository. Let's see what that might look like:
As you can see - when syncing to a service spec, you can specify the location of the spec to use. If you don't provide an explicit spec location - Proton will default to
./service-spec.yaml.Dependencies between service instances
Another feature we want to help folks with is ordering syncs. Within a particular branch we want to let folks tell us if there are dependencies between two service instances. Taking our example from above, let's have
bob-svcdepend ondaves-svc:Publishing
Another feature we're planning on supporting is the ability to
publishafter a commit is synced. This will let customers automatically issue pull requests to (for example), another branch. Let's see how this might look:In this example, once all syncs from the main branch are complete, Proton will create a pull request to prod with the contents of the
mainbranch. We realize that sometimes you might want more control over your publish (what files, what content within a file, etc). We'll save the design of what that might look like for another design issue.Feedback 👂
So I hope this helps keep ya'll up to speed with what we're trying to build! We're still early on in the design of this feature, so we'd LOVE your feedback. Specifically around the format of the
proton-opsfile. Is the experience intuitive? Do you have any recommendations? In a follow up post I'll show some otherproton-opsfile layouts we're considering and we'd love your help choosing one which works best.