github.com/GoogleContainerTools/skaffold/v2@v2.13.2/docs-v2/content/en/docs/workflows/ci-cd.md (about)

     1  ---
     2  title: "Continuous Delivery"
     3  linkTitle: "Continuous Delivery"
     4  weight: 40
     5  ---
     6  
     7  
     8  {{< alert title="Note">}}
     9  Skaffold is used under the hood to power Google Cloud Platform's [Cloud Deploy API](https://cloud.google.com/deploy).  See the docs [here](https://cloud.google.com/deploy/docs/using-skaffold) for more information on how to use Skaffold + Cloud Deploy for CI/CD
    10  {{</alert>}}
    11  
    12  Skaffold provides several features and sub-command "building blocks" that make it very useful for integrating with (or creating entirely new) CI/CD pipelines.
    13  The ability to use the same `skaffold.yaml` for iterative development and continuous delivery eases handing off an application from a development team to an ops team.
    14  
    15  Let's start with the simplest use case: a single, full deployment of your application.
    16  
    17  ## Run entire pipeline end-to-end
    18  {{< maturity "run" >}}
    19  
    20  `skaffold run` is a single command for a one-off deployment. It runs through every major phase of the Skaffold lifecycle: building your application images, tagging these images (and optionally pushing them to a remote registry), deploying your application to the target cluster, and monitoring the created resources for readiness.
    21  
    22  We recommend `skaffold run` for the simplest Continuous Delivery setup, where it is sufficient to have a single step that deploys from version control to a cluster.
    23  
    24  For more sophisticated Continuous Delivery pipelines, Skaffold offers building blocks:
    25  
    26  - [status-check]({{<relref "/docs/status-check">}}) - 
    27  wait for `deployments` to stabilize and succeed only if all deployments are successful
    28  - [`skaffold build`]({{<relref "/docs/workflows/ci-cd#skaffold-build-skaffold-deploy">}}) - build, tag and push artifacts to a registry
    29  - [`skaffold deploy`]({{<relref "/docs/workflows/ci-cd#skaffold-build-skaffold-deploy">}})  - deploy built artifacts to a cluster
    30  - [`skaffold render`]({{<relref "/docs/workflows/ci-cd#skaffold-render-skaffold-apply">}})  - export the transformed Kubernetes manifests
    31  - [`skaffold apply`]({{<relref "/docs/workflows/ci-cd#skaffold-render-skaffold-apply">}}) - send hydrated Kubernetes manifests to the API server to create resources on the target cluster
    32  
    33  ## Traditional continuous delivery
    34  
    35  `skaffold build` will build your project's artifacts, and push the build images to the specified registry. If your project is already configured to run with Skaffold, `skaffold build` can be a very lightweight way of setting up builds for your CI pipeline. Passing the `--file-output` flag to Skaffold build will also write out your built artifacts in JSON format to a file on disk, which can then by passed to `skaffold deploy` later on. This is a great way of "committing" your artifacts when they have reached a state that you're comfortable with, especially for projects with multiple artifacts for multiple services.
    36  
    37  Example using the current git state as a unique file ID to "commit" build state:
    38  
    39  Storing the build result in a commit specific JSON file:
    40  ```bash
    41  export STATE=$(git rev-list -1 HEAD --abbrev-commit)
    42  skaffold build --file-output build-$STATE.json
    43  ```
    44  outputs the tag generation and cache output from Skaffold:
    45  ```bash 
    46  Generating tags...
    47   - gcr.io/k8s-skaffold/skaffold-example:v0.41.0-17-g3ad238db
    48  Checking cache...
    49   - gcr.io/k8s-skaffold/skaffold-example: Found. Tagging
    50  ```
    51  
    52  The content of the JSON file
    53  ```bash 
    54  cat build-$STATE.json
    55  ```
    56  looks like: 
    57  ```json
    58  {"builds":[{"imageName":"gcr.io/k8s-skaffold/skaffold-example","tag":"gcr.io/k8s-skaffold/skaffold-example:v0.41.0-17-g3ad238db@sha256:eeffb639f53368c4039b02a4d337bde44e3acc728b309a84353d4857ee95c369"}]}
    59  ```
    60  
    61  We can then use this build result file to deploy with Skaffold:
    62  ```bash
    63  skaffold deploy -a build-$STATE.json
    64  ```
    65  and as we'd expect, we see a bit of deploy-related output from Skaffold:
    66  ```bash
    67  Tags used in deployment:
    68   - gcr.io/k8s-skaffold/skaffold-example -> gcr.io/k8s-skaffold/skaffold-example:v0.41.0-17-g3ad238db@sha256:eeffb639f53368c4039b02a4d337bde44e3acc728b309a84353d4857ee95c369
    69  Starting deploy...
    70   - pod/getting-started configured
    71  ```
    72  
    73  ## Separation of rendering and deployment
    74  {{< maturity "apply" >}}
    75  
    76  Skaffold allows separating the generation of fully-hydrated Kubernetes manifests from the actual deployment of those manifests, using the `skaffold render` and
    77  `skaffold apply` commands. 
    78  
    79  `skaffold render` builds all application images from your artifacts, templates the newly-generated image tags into your Kubernetes manifests (based on your project's deployment configuration), and then prints out the final hydrated manifests to a file or your terminal.
    80  This allows you to capture the full, declarative state of your application in configuration, such that _applying_ the changes to your cluster can be done as a separate step.
    81  
    82  `skaffold apply` consumes one or more fully-hydrated Kubernetes manifests, and then sends the results directly to the Kubernetes control plane via `kubectl` to create resources on the target cluster. After creating the resources on your cluster, `skaffold apply` uses Skaffold's built-in health checking to monitor the created resources for readiness. See [resource health checks]({{<relref "/docs/status-check">}}) for more information on how Skaffold's resource health checking works.
    83  
    84  *Note: `skaffold apply` always uses `kubectl` to deploy resources to a target cluster, regardless of deployment configuration in the provided skaffold.yaml. Only a small subset of deploy configuration is honored when running `skaffold apply`:*
    85  * deploy.statusCheckDeadlineSeconds
    86  * deploy.kubeContext
    87  * deploy.logs.prefix
    88  * deploy.kubectl.flags
    89  * deploy.kubectl.defaultNamespace
    90  * deploy.kustomize.flags
    91  * deploy.kustomize.defaultNamespace
    92  
    93  {{<alert title="Note">}}
    94  `skaffold apply` attempts to honor the deployment configuration mentioned above.  But when conflicting configuration is detected in a multi-configuration project, `skaffold apply` will not work.
    95  {{</alert>}}
    96  
    97  `skaffold apply` works with any arbitrary Kubernetes YAML, whether it was generated by Skaffold or not, making it an ideal counterpart to `skaffold render`.
    98  
    99  ### GitOps-style continuous delivery
   100  
   101  You can use this separation of rendering and deploying to enable GitOps CD pipelines.
   102  
   103  GitOps-based CD pipelines traditionally see fully-hydrated Kubernetes manifests committed to a configuration Git repository (separate from the application source), which triggers a deployment pipeline that applies the changes to resources on the cluster.
   104  
   105  ### Example: Hydrate manifests then deploy/apply to cluster
   106  
   107  First, use `skaffold render` to hydrate the Kubernetes resource file with a newly-built image tag:
   108  
   109  ```code
   110  $ skaffold render --output render.yaml
   111  ```
   112  ```yaml
   113  # render.yaml
   114  apiVersion: v1
   115  kind: Pod
   116  metadata:
   117    name: getting-started
   118    namespace: default
   119  spec:
   120    containers:
   121    - image: gcr.io/k8s-skaffold/skaffold-example:v1.19.0-89-gdbedd2a20-dirty
   122      name: getting-started
   123  ```
   124  
   125  Then, we can apply this output directly to the cluster:
   126  
   127  ```code
   128  $ skaffold apply render.yaml
   129  
   130  Starting deploy...
   131   - pod/getting-started created
   132  Waiting for deployments to stabilize...
   133  Deployments stabilized in 49.277055ms
   134  ```