github.com/wmuizelaar/kpt@v0.0.0-20221018115725-bd564717b2ed/site/book/02-concepts/02-workflows.md (about)

     1  In this section, we'll describe the typical workflows in kpt. We say "typical", because there is no
     2  single right way of using kpt. A user may choose to use some command but not another. This
     3  modularity is a key design principle. However, we still want to provide guidance on how the
     4  functionality could be used in real-world scenarios.
     5  
     6  A workflow in kpt can be best modelled as performing some verbs on the noun _package_.
     7  For example, when consuming an upstream package, the initial workflow can look like this:
     8  
     9  ![img](/static/images/lifecycle/flow1.svg)
    10  
    11  - **Get**: Using `kpt pkg get`
    12  - **Explore**: Using an editor or running commands such as `kpt pkg tree`
    13  - **Edit**: Customize the package either manually or automatically using `kpt fn eval`. This may
    14    involve editing the functions pipeline in the `Kptfile` which is executed
    15    in the next stage.
    16  - **Render**: Using `kpt fn render`
    17  
    18  First, you get a package from upstream. Then, you explore the content of the package to understand
    19  it better. Then you typically want to customize the package for you specific needs. Finally,
    20  you render the package which produces the final resources that can be directly applied to the
    21  cluster. Render is a required step as it ensures certain preconditions and postconditions hold
    22  true about the state of the package.
    23  
    24  This workflow is an iterative process. There is usually a tight Edit/Render loop in order to
    25  produce the desired outcome.
    26  
    27  Some time later, you may want to update to a newer version of the upstream package:
    28  
    29  ![img](/static/images/lifecycle/flow2.svg)
    30  
    31  - **Update**: Using `kpt pkg update`
    32  
    33  Updating the package involves merging your local changes with the changes made by the upstream
    34  package authors between the two specified versions. This is a resource-based merge strategy,
    35  and not a line-based merge strategy used by `git merge`.
    36  
    37  Instead of consuming an existing package, you can also create a package from scratch:
    38  
    39  ![img](/static/images/lifecycle/flow5.svg)
    40  
    41  - **Create**: Initialize a directory using `kpt pkg init`.
    42  
    43  Now, let's say you have rendered the package, and want to deploy it to a cluster. The workflow
    44  may look like this:
    45  
    46  ![img](/static/images/lifecycle/flow3.svg)
    47  
    48  - **Initialize**: One-time process using `kpt live init`
    49  - **Preview**: Using `kpt live apply --dry-run`
    50  - **Apply**: Using `kpt live apply`
    51  - **Observe**: Using `kpt live status`
    52  
    53  First, you use dry-run to validate the resources in your package and verify that the expected
    54  resources will be applied and pruned. Then if that looks good, you apply the package. Afterwards,
    55  you may observe the status of the package on the cluster.
    56  
    57  You typically want to store the package on Git:
    58  
    59  ![img](/static/images/lifecycle/flow4.svg)
    60  
    61  - **Publish**: Using `git commit`
    62  
    63  The publishing flow is orthogonal to deployment flow. This allows you to act as a publisher of an
    64  upstream package even though you may not deploy the package personally.