James Strachan
Jul 24, 2017 · 1 min read

Thanks Jeroen, I’ll look out for your blog.

Whether you use minikube or use a separate kubernetes namespaces per developer, the key is to always be running inside kubernetes really as much as possible for anything above simple unit tests — as then you are running/debugging/testing on as near to production as possible.

The issue with ‘running locally’ when thats not in kubernetes is you are probably running a different operating system, libraries, dependencies, file system, network stack, environment variables and whatnot — which means you are kinda wasting time testing on a totally different platform and could be hiding real issues you will hit when you really run things on linux on kubernetes etc.

There are various ways to do this though. Minikube is one option; custom namespaces are other. When using OpenShift.io / fabric8 4.x or later you can use Che as a cloud based IDE; this feels much like using your local laptop. The massive difference though is every time you run something (e.g. java -jar foo.jar or some npm goal or go binary) its always running inside kubernetes in a docker container — as close to production as possible even in development.

    James Strachan

    Written by

    I created Groovy and Apache Camel. I’m currently working at CloudBees on Jenkins X: automated CI/D for Kubernetes: https://jenkins-x.io/