This topic tells you about the SupplyChain
primitive in Tanzu Supply Chain. The SupplyChain
primitive unifies the Tanzu Supply Chain operation. For reference information, see SupplyChain.
CautionTanzu Supply Chain is currently in beta and is not intended for production use. It is intended only for evaluation purposes for the next generation Supply Chain. For the current Supply Chain solution, see the Supply Chain Choreographer documentation.
In physical manufacturing a supply chain is the process that delivers an end product to customers, starting with the raw materials. In software, a supply chain delivers an operational end product to customers, starting with source code. VMware refers to this as the golden path to production.
Tanzu Supply Chain provides a primitive called SupplyChain
, which is a Kubernetes custom resource that you use to define all, or portions of, your software supply chain.
This section describes typical uses of the SupplyChain
primitive for Tanzu Supply Chain.
A SupplyChain
primitive can describe the process of converting source code into a runnable or deployable package.
Typical stages in this process are:
A SupplyChain
primitive brings together the API for a user to apply to the cluster by:
Workload
. For reference information, see spec.defines.SupplyChain
. For reference information, see spec.stages[].By selecting components, SupplyChain
aggregates each configuration for each component as a single API specification for the Workload
.
Note
Workload
might be renamed in a later Tanzu Application Platform version.
The version of your SupplyChain
primitive that is embedded in the name must adhere to the rules described in this section.
A patch update is required to update SupplyChain
without an API change. The controller ensures that this rule cannot be broken when comparing SupplyChain
primitives on the cluster.
For example, you can apply to a cluster:
SupplyChain
primitive with the name serverappv1s.example.com-1.0.0
and the kind ServerAppV1s
SupplyChain
primitive with the name serverappv1s.example.com-1.0.1
and the kind ServerAppV1s
If the generated API for the kind is unchanged, then the later version is accepted. If there is a change, the SupplyChain
primitive that was applied first succeeds, and the others reflect the error in their statuses. This rule ensures that you cannot accidentally break the kind API that is running.
These rules ensure that potentially thousands of Workload
and Run
resources on the cluster do not break.
Recommended version practices:
spec.stages
:
1.2.5
to 1.2.6
ServerAppV1
spec.stages
, consider:
1.2.5
to 1.3.0
ServerAppV2
ServerAppWithApprovalV1
1.2.5
to 1.3.0
ServerAppV2
This ensures effective communication to your users. New kind versions typically indicate that the user must migrate their resources to the new API.
A SupplyChain
primitive is not valid if:
Component
resources referenced are not in the same namespace.Component
resources referenced contain values that are not satisfied by their position in spec.stages
.spec.defines
section.SupplyChain
breaks the versioning rules.For more information, see status.conditions[].