What do you, professional developers, use for you day-to-day work on remote servers? My thought was that vim / emacs / rmate + Sublime for configuration files and git for well-defined projects were the norm, but I'm curious about what people use for their work.
Not everyone has the same workflow, partly because not everyone has the same work.
You're entirely missing the point; there are reasons to manually make contact with a server aside from deploying.
I would still run my editor locally (your pick. I use vim almost exclusively).
Migrated my emacs configuration to the remote server as a git repository, along with any programs that aren't available (e.g. git, which I use for unofficial code; official code is managed via perforce). Use GNU stow to move those configurations and binaries to the right places. If I need to move non-confidential information around I collect it in an emacs buffer and then use M-x compose-mail to send it out. The home directory is an NFS mount so I can also mount my home directory and exchange files that way. Etc, etc.
I also set up a lightweight Arch virtualbox VM that I SSH out of, because I really don't like the available Windows terminal applications, and every so often I need a local Unix box for some random reason.
A lot of my coworkers use Sublime and remote file editing, but I work faster when using Emacs (comint-mode is a godsend). We mainly work in Perl, Javascript, and HTML so none of the bigger IDEs are really appropriate.
Edit Since people seem more interested in the Sublime workflow, I asked for a few more details. Coworker replied: "Sublime SFTP [...] you might want to mention that the only advantage to SFTP over remote mounting the server is the save time, as with SFTP, you save local and push in the background, meaning frequent saves don't constantly stall workflows. Otherwise, there is no real advantage over just mounting directly." It is worth noting that he is working on a Mac, which has some severe bugs [1] when it comes to NFS mounts, and Samba has some latency issues in this instance.
[N]o local copies of development files are allowed
... without special authorization
1) The developers in this company that work with ColdFusion develop their software on a dev server because they would otherwise require expensive licenses for each dev machine. This means that devs often find themselves editting the same file. It also means that one dev can break the software for all other devs. Last but not least, it makes version control a ton harder.
2) Another scenario is where you fix a bug on the production server to roll out a fix as soon as possible. Sometimes this is acceptable, but there's a big risk because you no longer have the ability to test the code first. This also makes version control harder, because the next time you deploy your code, the changes will get overwritten.
3) Working with a remote IDE or just having your own development server: doesn't really make any sense, most devices (laptops, PCs, tablets) can run some kind of IDE/editor locally and allow you to run the code locally. Using remote software only adds a huge dependency on having a working internet/network connection.
However, I don't do remote development as much anymore since I picked up the habit of using Vagrant locally. Now I can edit the files locally (though still with Vim), and debug them on a local VM. Throw in Salt and Ansible for orchestration, and once I get my local VM working, I know my remote end will work as well.
To get around this shortcoming, the sharing is mostly one way: from the host to the VM, via the default shared folder. I've not had problems with VBFS when managing files in this manner.
There have also been times where I have implemented watch scripts against files on the host, which triggers a rsync to the guest's normal file systems. From there, the file system behavior is more like what we can expect from a typical virtual machine.
To support workflows similar to what I do against non-local VMs, I've worked up some wrapper scripts which allow me to interact with the Vagrant VM via the usual ssh, scp, and rsync. When running "vagrant up", I also write out the VM's SSH configs and a ssh alias concatenates these with my base .ssh/config file.
Vagrant itself acts as a user-friendly wrapper around the creation and management of local virtual machines.
There are ways to use Vagrant to create and push machine images up to cloud providers, but we're not at a point with our deployments where machines are so easily interchangeable.
http://docs.saltstack.com/en/latest/contents.html http://docs.ansible.com/intro.html
Otherwise, some combination of tmux and vim/nano/emacs.
On OSX, I use Panic Transmit's "Mount as Disk" feature. I've also heard good things about a product called WebDrive for this use case.
I have a hard time disagreeing with this, since quite a bit of my professional life involves writing such configuration files.
That said, even in the cases you describe, I at least try and set up a shell script or makefile to keep things repeatable and documented.
edit: also sshfs, tho that isn't always a smooth experience
As for tools, well vim is my default editor so:
vim (really lots of plugins, themes, extension support, personal .rc, etc.) + tmux (tmuxinator for projects) + ssh (heavy user, I use sockets to keep the connection up, use keys-only access, fine-tune the algorithms I use, etc.).
Of course.. people never stopped. Anyone using Wordpress, for instance, will almost certainly require developers to use FTP. For most shared hosts, FTP is the default (if not only) available method for getting files on and off of the server (and yes, people still use shared hosting as well.) I would even venture to guess that "Save in Notepad, FTP to live server and F5 to see if it worked" is still the most common web development workflow in existence.
I recently read a blog post of a guy who started coding on a cloud VM using an iOS SSH app + bluetooth keyboard. He never stopped. The setup forces you to only work with SSH and eliminates distractions.
I've read it a while ago. Of course if you only use command-line editors, it's nice. But some people prefer Sublime or other graphical editors.
I can't believe how few people mentioned mosh. I work on remote boxes "across the pond" all the time and it makes a huge difference. Laptop going to standby, VPN dropping, slow connection, all handled perfectly.
It's "smarter" than sshfs/fuse, because tramp understands which files are remote, and which are local.
[1] https://stackoverflow.com/questions/15958056/how-to-use-subl...
- Sometimes I mount the remote servers file system locally over SSH (sshfs) so I can use my local development environment. I generally do this when I have more complex projects (eg quantity of files) and there's some prerequisites defined on the server (ie it's easier to develop on the server than it is to mimic the set up on my local machine)
- Sometimes I use tmux and vanilla vi / vim (I don't generally bother with plugins / config for editors so I don't miss them when jumping onto new systems). I generally only do this if it's small changes though. The kind of situation where it would be quicker to SSH in and make a few edits than it would be to follow a stricter development and deployment model.
- Sometimes I develop locally and then push the changes remotely (usually using rsync, scp, git). This is usually for new projects and where there aren't prerequisites specific to the remote host.
My preferred development model would be 1 (as it's ridiculously lazy), then 3 (as it better follows sane development and deployment models). But sometimes a job simply requires you to make quick edits via vi; and thankfully I feel as at home in vi as I do with most GUI text editors.
Just to add, there's only two config files I ever need to worry about:
.tmux.conf which I only put on a small handful of development machines where I'd like detachable sessions from multiple client (eg home/work/etc). But generally I will run tmux locally.
env_servers which is an epic environment script (like .bashrc) that I can call in as and when and it has a whole stack of aliases, functions and such like optimize my workflow. I've also set up an alias on my local machine to auto scp my env_servers script to any server I SSH into. Thus keeping env_servers available and up-to-date.
In particular, the Twelve Factor App (http://12factor.net/) (by the founder of Heroku) had a big impact in my thinking of how to remotely deploy and administer. In particular "1. One codebase tracked in revision control, many deploys" and "X. Keep development, staging, and production as similar as possible". Note that these approaches are applicable to any hosting provider and technology.
Now, there are times (especially when you're debugging a breakdown in dev/prod parity) where it is enormously helpful to ssh into a remote machine. But I would endeavor to minimize those occurrences.
No need for dotfiles or tools on the remote.
SSH into the box, checkout my dotfiles from github (or SCP them), edit text files with emacs, or whatever else I have to do.
Supports full directory synchronization, has a nice UI and can be installed on a flash drive.
Depends on project, if it is JavaEE app, or Android, then you're screwed and might as well work on a local version, because you need IntelliJ.