Editing code directly on a remote server is something I used to do in the 90s before git and other tools made good practices much easier.
Editing code directly on a remote server is something I used to do in the 90s before git and other tools made good practices much easier.
The next 10 years of “best practices” will return to dumb clients and dynamically provisioned dev environments. It’s simply so much easier.
I'm not sure if the price lines up well enough for a daily-drive for a company, but if I were managing dev environments for an org these days I'd probably jump to something similar. Perhaps something like a decent size EC2 on AWS where devs can tear it down and spin it up again to start from scratch within a couple minutes.
Throw away dev environments feels like a game changer having used it for the past 6 months on-the-go.
It baffles me why anyone would choose an incompatible architecture only to run dumb clients on it. You might as well just save your money and run the dumb clients on 20 year old hardware.
Or you could spend less money on a laptop that is actually compatible with whatever platform you are deploying to and enjoy low-latency local development.
My workflow was as follows
- Remote into server and develop from there
- Git to different location, could even be same server
- Occasionally pull on local machine for redundant backup
This allowed me to
- Segregate builds for my testing and the business's UAT
- Allowed me to always have a stable build locally that I could look at from home
Before, I did develop on my local machine and push to a server. Some part of me still thinks that's the proper way to do it.
But I am always seeing what works best for the current situation and developing directly on my server served me well once upon a time.