Written by Lior Ben David.
"If you're not using a live test environment, you're making your life harder than it needs to be."
Tell me if this sounds familiar?
You're building a backend application that's working exactly how you want it to on your local machine. Time to ship!
After setting up your hosting, you deploy, wait a minute or two, and…
It's not working right!
If this was your local machine you could see all the error messages and tweak things until it's working properly - but it's not. You have to figure out what in the world is wrong with your app by navigating your cloud's third-party error messages.
So now your only option is trying to debug locally, redeploy, and repeat. This process not only is long but it's frustrating.
You'd think as developers we wouldn't have to deal with this kind of bureaucracy.
Ship In A Bottle
Trying to debug your deployment without access to the actual deployment environment is like trying to fix a ship in a bottle.
Instead of having full access to what you need to fix, you're bottlenecked by your cloud provider.
As developers, we are trained in debugging, but we can't debug if we don't have all the information in front of us.
That's the issue with not having a live test environment. Deploying locally is rarely difficult because we can see what goes wrong. Deploying in the cloud, however, creates an information asymmetry that takes way too much time, resources, and headspace to navigate.
Shopify, Slack, And More
A whole different layer to this issue exists when you're building something like a Shopify or Slack app, that can only be tested when hosted live.
When building software like this, testing locally becomes nearly impossible, forcing you to play the cloud waiting game any time you want to test your code.
What if working in your cloud environment was as easy as working locally?
Development doesn't have to be this way. If you're not using a live test environment, you're making your life harder than it needs to be.
A live test environment will allow you to debug your code directly in the cloud, where it's going to be deployed. This way, anything that goes wrong in deployment will be fully visible to you and you can make sure everything is working exactly how you need it.
Additionally, debugging directly in the cloud means no more waiting for your app to deploy just to find out if it works. Running in the cloud can be just as easy as it is on your local machine.
That's what we're building at Codesphere, an intuitive cloud provider meant to give you full, live access to the cloud environment, including the terminal, monitoring, and file system(Through a web IDE).
Our goal is to take the bottlenecks out of shipping your app (see what I did there?), so you can spend less time debugging your deployment, and more time actually coding.
Is this a problem you've been facing? Let us know down below!
Oldest comments (10)
My company could really use something like this! Great concept, excited to see it in action!
I'm the head of our QA dept and what I'd give to stop hearing, "Well, it worked for me locally.. "
Thank you! Feel free to try us out, we would love to hear your feedback :)
Hey Sal, I am the part of the product team building Codesphere, you sound like just the kind of person Im looking to talk to. Maybe we can jump on a call sometime?
Isn't this what docker is for? Allowing you to control the env in a container then the local copy matches the remote because it is the same container
Your solution sounds like devs would be forced to use your web IDE?
Hi Todd, so Docker definitely solves the issue for a lot of use cases, though for certain apps when it can’t sufficiently be tested locally(ie Shopify Apps, Slack Bots, or Game Servers), Docker can only get you so far. Not to mention what happens when you have to debug Docker…
And as for your question about the IDE, we’re working on a VSCode extension to allow people who prefer their local IDE to get the full power of Codesphere without being locked-in!
A nice funnel for that VC money 💸💰🤣
You should do both. The constraints of local dev can uncover poor design and complexity.
Avoiding that pain can cause more for others.
Also for tracing remote bugs, APN and 12-factor services (with logging) can help you trace. It is always more of a pain remotely troubleshooting though.
Hi Lewis, the idea behind what we’re building is to add all the benefits of a local test environment to a live test environment so you can get the best of both worlds!
I test on a very underpowered local kubernetes cluster that mirrors my production environment (in every way but # of nodes). Best of both worlds.