DevSpace is a lightweight open-source CLI tool that enables local and remote development environments in Kubernetes.
▬▬▬▬▬▬ 🔗 Additional Info 🔗 ▬▬▬▬▬▬
➡ Gist with the commands: https://gist.github.com/6955a3fa05665c6b8bb7a3a48ebbdd23
🔗 DevSpace: https://devspace.sh
🎬 vCluster: https://youtu.be/JqBjpvp268Y
🎬 Argo CD: https://youtu.be/vpWQeoaiRM4
🎬 Flux CD: https://youtu.be/R6OeIgb7lUI
🎬 K3d: https://youtu.be/mCesuGk-Fks
🎬 Kustomize: https://youtu.be/Twtbg6LFnAg
▬▬▬▬▬▬ 🚀 Courses, books, and podcasts 🚀 ▬▬▬▬▬▬
📚 DevOps Catalog, Patterns, And Blueprints: https://www.devopstoolkitseries.com/posts/catalog/
📚 Books and courses: https://www.devopstoolkitseries.com
🎤 Podcast: https://www.devopsparadox.com/
💬 Live streams: https://www.youtube.com/c/DevOpsParadox
▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬
➡ Follow me on Twitter: https://twitter.com/vfarcic
➡ Follow me on LinkedIn: https://www.linkedin.com/in/viktorfarcic/
Technology Conversations 
isn’t this the wrong video (kubesphere) in the “devspace” blog post?
Thank you for letting me know. Fixed!
@Viktor: it would be interesting to see, how the configuration of environments with crossplane could be reproduced in a dev environment – say you have a complex application that consists of many microservices – and you want do develop/change one of those – how can you test those changes in relation to the other microservices locally with devspace? (e.g. just have a backend, a redis or DB and a frontend – you want to test the frontend changes locally with devspace – ideally with the same infrastructure definitions you are using for the deployment later…)
Normally, both in local and in preview (PR) environments, I would focus only on the application I’m working on. Ideally, that app would be connected to its dependencies running in production and would not depend on unreleased stuff. If that’s not possible or practical, it can connect to its dependencies in staging. In either case, deploy the app you work on, and connect it to the dependencies running in permanent environments.
That being said, it’s even better if devs write mocks and stubs so that there is no need to connect to “real” dependencies or if everything is lightweight so that I could spin up everything I need independently from whatever other people are doing. However, for many that is not the option since “everything” can be very heavy and, in those cases, connecting temp envs (dev, preview) to permanent envs (prod, staging) is the alternative.
Thanks for your feedback. Well, in reality applications sadly (but also luckily) depend on each others services and functionalities (at least in my world ;-)).
Yes, connecting to staging might be a good solution. But as soon as you need to depend on data being available/created in the “external” components, then it get tricky.
Mocks are a great way for dealing with that – but they need to be “created” and “maintained”.
I thought in the world of docker/kubernetes – it should not be very difficult to just bring the right version of the dependency to the dev environment?!?
So yes, I would go for the lightweight approach (download and spin up everything independently).
And now, back to my question:
Is there a good way to achieve that with DevSpace?
The simplified version of the explanation of what DevSpace does is that it applies whichever manifests you tell it to apply, it modifies the image to be whatever DevSpace builds, and it synchronizes files between the file system and the container based on that image. As long as your manifests (those you tell DevSpace to use) contain all the apps you need, the mission is accomplished. Right?
In the video I have only seen, that you change the “image”. But if you can specify manifests around it, this will do the trick.
Great, thanks. Mission accomplished 😉
The
devspace initcommand asks you about the location of the manifests. In my case, I used Kustomize and, with it, I would just add dependencies as (probably) external sources tooverlays/dev/kustomization.yamlfile. If it would be Helm, those would be entries independencies. On top of all that, you can fine-tune what it does throughdevspace.yamlfile.