Connecting to a server using ssh coding directly on the server, while it can be beneficial at first because the changes are directly deployed, will usually prove to be bad, because if you realize you have changed a lot of code and the code does not work, you need to go through all the code again and carefully remove it.
The pretty much standard today are VCSs. There are many options, including Git, Apache Subversion, Mercurial and others. Git has been very popular lately, mainly due to its simplicity, stupidity and distribution.
I cannot speak for Apache SVN and Mercurial, considering I have little to no experience using them.
With Git, you usually have one bare repository and unlimited amount of working repositories (usually local copies). When you clone a project from a bare repository to your own PC, you don't only copy the files but you copy the history as well. Meaning as long as your local project is up to date, if your main server containing the bare repository ever died, you can take the local repository you have, push it to a new server and you will be where you were before.
The workflow with git specifically is usually done like this:
- a bare repository is created on a server (usually containing master branch representing the latest production-ready application version)
- developer pulls the repository to his local machine
- (optional) developer creates a branch to isolate his changes from the global branch/namespace (if he creates a branch, until he pushes it to the bare repository, the branch will be only available to him, locally)
- developer makes changes to the project (local work)
- developer makes sure the changes work (local work)
- developer commits the changes and pushes them to the branch he is working on (affects the bare repository on the server)
- (optional) should the developer work on a custom branch he created, he will merge this custom branch to branch used for building either directly or using a merge request/pull request
With Git, all the changes to the code are performed locally, none on the server directly. After the changes are completed and working, then the local code is taken and merged to the production version of your application.
With branching and Git you have the great option to undo large code changes very quickly, such as you very coding a feature which should be only available during a part of the year, like Christmas. Before Christmas you coded it, during christmas you deployed it, and after christmas, you can simply undo a commit responsible for the addition of the christmas bundle to the main project and it will be removed.
For the code itself, considering git is distributed, all your peers working on the project will have a complete copy of the project including history on their local machines, you don't really need a sophisticated backup system anymore. Unless your, the server and all your peers' machines died at the same time, you will always have a source to pull the project from, be it your local machine or one of your peers'.
Databases are usually not versioned, so if you do not want to lose your data, they should be backed up regularly. The first step is RAID configuration, mirroring the disk with database to a second one. An option is master/slave replication, which represents backing up in a slightly more complicated manner (as long as the slaves are up to date with master).
To answer the questions shortly...
Currently we're all developing code in a shared folder on the server.
Is that standard practice, or would people normally code in private
user areas and transfer production-ready code to a shared space?
Not a good idea. Try to get hand on a VCS and use that one instead. Editing files directly on the server may be a good idea for tiny changes to code, not so much for development.
Would the coding normally be done on the host server itself? Or would
it normally be done locally and then somehow transferred to the server
(if so, how?)?
Locally is defenitely a better idea. You can test the changes on your local machine without directly affecting the server and its code.
Is there a particular kind of backup system that a project like this
If you use Git, there you won't really need to backup the project itself. You will still need to find a way how to backup a database, possibly using some RAID.
Are there other considerations we might be missing?
Continuous integration comes in mind. Where I work we use Jenkins. It's a tool to automate the process of deploying your application to the production server. During it Jenkins can perform specific tasks such as running unit/integration tests.
You will need to configure at first, but once that is done and it is linked to your repository, you can easily build it from a selected branch and it will do all the checks that need to be done (according to your configuration) and if the checks pass deploy the code to your production machine.
I think part of the reason that writing code on the server itself
seemed so appealing is because of the database. Since the database is
hosted on that server, how can I try out my database-altering code
locally? Is it standard to have a copy of the database on one's local
If not, what's the typical alternative for evaluating database code?
Is there a standard way to continuously see if each new method is
working properly as I'm writing them? Is that just not normally done?
Commit after every couple methods and test remotely? I think I'm just
generally confused about the standard practices for this part.
If you have only one version of the database right now, you really should make a backup to your local machine or a development server and when you develop, use this copy instead.
You should not be testing changes to the code on the production database, that's a really bad idea. What if you change a removal procedure, run it and during the run realize it does not do what it is supposed to do and thousands of records are suddenly marked as deprecated or worse, completely removed.
If they are marked as deprecated, good luck fixing your database for the next 7 days, if they are removed, you can probably pretty much close the shop.
Generally speaking, you want only production-ready code on your production server. Production-ready code, which is tested that works. Nothing else. Do all your work locally, test it on a dummy database, where you can insert/update/delete whatever you want, and once you are sure the code works, then deploy it to the production server, not before.