Rollback your Kubernetes application when things go wrong.

Low code solution providing application-level rollback without custom CD scripting.

Interested in learning more?

We are looking for a select few early adopters/design partners.

13 + 10 =

The Problem:

You’ve built a microservice application, created your Kubernetes clusters, deployed your application and everything is working smoothly.  You update your application, test it, then deploy it to production. Only then do you realize your testing was insufficient and you’ve found a critical bug in production!  

You can rollback your deployments individually – but you don’t have a proper tagging scheme for your images. You aren’t sure which service versions work with other services versions, so that won’t work.  Now you’re stuck either guessing which deployments to roll back, or shutting your system down until you can triage the issue, find the fix, and re-deploy.

This sucks for everyone; your users, your team, your manager and yourself.

The Solution:

Our newest on-premise version of Yipee is enhanced to not only visually model your applications but deploy, manage, and rollback when things go wrong.  It works with your existing CD process so there are no complicated scripts to develop and maintain. Features and capabilities include:

Features include:

Pluggable rollback processing

Multiple deployment strategies – including canary deployment
On-premise or cloud Kubernetes

Application deployment history with graphical diffs

Browser UI and APIs

App manifests in Helm and/or straight Kubernetes YAML

Track image changes with or without tags

To learn more about rolling back Kubernetes applications, check out  Simplified Kubernetes Application rollback with Yipee.io by Dann Church.

Interested in learning more?

We are looking for a select few early adopters/design partners.

5 + 9 =