TL;DR The newly introduced zarf dev deploy can greatly speed up Zarf package dev cycles.

I adapted much of this article from the ADR I wrote for zarf dev and zarf dev deploy

Who cares?

Well, Jeff told me my job was on the line if I didn't do it, so that was reason enough for me to implement. (for legal reasons that was a joke)

But in all seriousness anyone who develops Zarf packages should take note and try out this pretty slick feature.

If it ain't broke make it better

it can be better

The Zarf package debug/development feedback loop varies significantly depending on the encountered bug or added feature. Generally though, the cycle follows:

  1. Create/edit a zarf.yaml file and components
  2. Build the package w/ zarf package create
  3. Debug any create errors and resolve by editing the zarf.yaml and repeating step 2
  4. Run zarf init against a fresh running cluster
  5. Deploy the local tarball w/ zarf package deploy <tb>
  6. Debug any deploy errors and resolve by editing zarf.yaml and repeating steps 2 or 5

If there are deployment errors, the common pattern is to reset the cluster (ex: k3d cluster delete && k3d cluster create) and repeat steps 4-6. Re-initializing the cluster, recreating the package, and redeploying the package is tedious and time consuming (~1.5 minutes on my beast of a dev machine); especially when the package is large or the change was small.

So what's the bottleneck?

The foundation of Zarf is turning technologies geared towards fully connected environments and making them air-gap native.

As such, zarf package create is designed around a zero knowledge approach. It can't make any assumptions about the connected nature of the environment it's being created for (unless .metadata.yolo == true). This means that any dependencies referenced (whether they are container images, git repos, helm charts, files, etc...) must be retrieved/assembled each and every run.

There already exists the concept of YOLO mode, which can build + deploy a package without the need for zarf init, and builds without fetching certain heavy dependencies (like container images). However, YOLO mode isn't exposed via CLI flags, and is meant to develop and deploy packages in fully connected environments.

The new hotness

Starting with Zarf v0.32.0, the zarf dev deploy command is available.

zarf dev deploy has a number of flags that closely match a combination of flags from zarf package create and zarf package deploy, but there are some differences (for example --set is split between --create-set and --deploy-set)

To view all the flags run zarf dev deploy --help

zarf dev deploy combines the lifecycle of zarf package create and zarf package deploy into one command. It also has the following features:

  • No --confirm or interactive prompts (it's dev mode after all)
  • Only builds & deploys components that will be deployed (contrasting with a traditional zarf package create which builds all components each time)
  • Can create & deploy in either YOLO mode (default) or prod mode (similar to a regular zarf package create)

If the current goal is to test whether or not a package's Helm charts, Kustomizations, K8s manifests, etc... work properly; a normal zarf dev deploy will suffice.

If the current goal is to more closely replicate a full zarf package create && zarf package deploy: zarf dev deploy --no-yolo is more the move.

NOTE:

In order for zarf dev deploy --no-yolo to function, zarf init must be run first. There may be an introduction of zarf dev init to speed this process up, but for now this is the current strategy. The speed benefits of zarf dev deploy combined with it being marked as [beta] lead the team to believe it was better to get the feature out the door and into the hands of users rather than wait for the entire devx experience to be revamped.

What changed

In order to enable zarf dev deploy to be possible, there was some cleanup that had to happen to some lifecycle helper functions during create.

As a result, create has been distilled down into three high level stages (each with their own sub helpers).

  • load
    • Read the zarf.yaml into memory
    • Resolve component imports + apply flavor + only filtering
    • Apply PKG_TMPL variables to the zarf.yaml
    • Process extensions
  • assemble
    • Run onCreate actions before + after assembling all components + dependencies into a fresh /tmp/zarf-* directory
    • Pull images + OCI artifacts
    • Generate SBOMs
  • output
    • Tarball up each components dependency directory
    • Generate package checksums.txt
    • Generate build metadata + write the in-memory zarf.yaml to temp
    • Sign the zarf.yaml (if provided a key)
    • Publish to an OCI registry or create a local tarball

For zarf dev deploy, only load and assemble are run. Using existing create logic, pulling images and generating SBOMs is controlled via the --no-yolo flag.

In contrast to zarf package create, after the load function has run, zarf dev deploy uses a helper function from deploy to filter down the components even more than --flavor and --arch.

The results of these lifecycle changes results in a command that's blazingly fast at taking a zarf.yaml and applying it to a local cluster. See for yourself:

Demo GIF

Takeaway

The introduction of zarf dev deploy in Zarf version 0.32.0+ marks a significant leap in the development workflow for Zarf packages. This streamlined command combines the creation and deployment process, offering a faster and more efficient way to test and deploy packages in both YOLO and production modes.