Blueprint Sources
Commonly, subsets of the K8s manifests that define your Velocity Blueprint will be committed to Velocity independently from other manifests, so future commits can be made according to these same logical groupings.
For example, a given K8s Deployment, Service and Ingress that combine to represent a Velocity Service called
web-api
may be managed together in a dedicated git repository.Alternatively, manifests may be generated as artifacts from CI/CD pipelines, or they may be drawn from Velocity's Service Catalog or elsewhere.
Velocity Blueprints accommodate this pattern of managing the versioning of distinct subsets of manifests within your Blueprint independently of other, unrelated manifests with the concept of "Blueprint Sources." When you commit a collection of manifests to Velocity, you will designate a
source
for that group of files. For example, you may run the following from the CLI to commit a logically grouped set of manifests:
veloctl blueprint commit -f web-api.yaml --source web-api
This way, when you update manifests related to the
web-api
Velocity Service in your Blueprint, only files included in this source
group will be updated.NOTE: Blueprint sources do not need to align with a given Velocity Service. For example, in addition to the above
web-api
source, your Blueprint may include a source that contains a K8s ConfigMap that informs multiple Velocity Services.To simplify making updates to such a ConfigMap, you can commit it to your Blueprint with a distinct
source
value, like so: veloctl blueprint commit -f config-map.yaml --source config
Takeaway: Your Blueprint is the combined result of any number of distinct sources.
Monolith Repo
GitOps Repo
'n' Sources to 'n' Velocity Services


.png?alt=media&token=feebd279-c4e9-4871-b82a-a1dd5c66bdde)
Last modified 3mo ago