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-apimay 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
sourcefor 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-apiVelocity Service in your Blueprint, only files included in this
sourcegroup will be updated.
NOTE: Blueprint sources do not need to align with a given Velocity Service. For example, in addition to the above
web-apisource, 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
sourcevalue, like so:
veloctl blueprint commit -f config-map.yaml --source config
Takeaway: Your Blueprint is the combined result of any number of distinct sources.
'n' Sources to 'n' Velocity Services