Fastest way to iterate on a Replicated Release

Packaging an application
1

A few options for iterating quickly, going from IDE to running in your dev environment.

Existing Cluster

  1. Create a new release: replicated release create --auto -y
  2. kubectl kots upstream upgrade $APPSLUG --deploy --skip-preflights -n $NAMESPACE

kURL Cluster

  1. Create a new release: replicated release create --auto -y
  2. SSH into your kURL cluster server and run:
  3. kubectl kots upstream upgrade $APPSLUG --deploy --skip-preflights -n $NAMESPACE

Skipping the Vendor API Entirely

There’s an even more advanced workflow that skips the Replicated Vendor Portal entirely that @Dom has shared below.

1 Like
2

Hey,

Is working with channels actually the best way for quick dev iterations? Doesn’t that mean that every developer requires a separate channel and that you will end up with tons of different releases?

What about having 1 channel, which is deployed by each developer separately (i.e. containing latest main release) to a fresh VM (for example), where iteration happens inside the cluster, rather then over the channels?

An example process:

  1. Take Staging channel, which contains the changes from the latest main (maybe a GitHub action creates a new release every time you merge a branch or commit to main)
  2. Run Replicated’s 1 liner (in case of embedded cluster)
  3. Once everything is installed, download manifests from local cluster.
kubectl kots download $APPSLUG --decrypt-password-values --dest $TMP_DIR --namespace $NAMESPACE
  1. Make any changes here inside your repository.
  2. Patch / replace downloaded manifests with the.changes you just made.
  3. Deploy new changes to the cluster.
kubectl kots upload --namespace $NAMESPACE --slug $APPSLUG $TMP_DIR/$APPSLUG/ --deploy --skip-preflights

The benefits I see here are:

  • Only 1 channel needed for development (stops polluting vendor portal with X dev channels)
  • The iteration cycles are very quick (commands usually takes 2-5 seconds to execute each)
  • No need to create releases and pollute release sequence.

Let me know your thoughts! I am keen to understand if I miss-understood the preferred DevEx when iterating over the product.

3 Likes
3

@Dom thank you for sharing this! Yes this is the exact workflow I was hinting at in #3! I know we’ve shared it in a one-off form a few times before but thank you for helping us make sure it is documented publicly!! :slightly_smiling_face:

4

For folks just finding this now, there’s also this blog post which could be helpful: Rapid release iteration with Replicated and Tilt