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.
Common Patterns for Managing Blueprint Sources
Monolith Repo
GitOps Repo
'n' Sources to 'n' Velocity Services
Last modified 3mo ago