From your StackOverflow account, I'm gonna guess you're a python shop.
I recommend using BZR as your VCS, but that's fairly irrelevant. Use whatever you and your developers are happiest with.
You should have (at least) one centralised development server.
This should hold a master copy of your repository, as well as home directories for your developers.
Take regular backups of this server.
Use rsnapshot to take in-progress snapshots of the data. Perhaps hourly snapshots, a nightly offsite backup (Amazon S3 is great value for money for this!).
Do a weekly backup to offline-medium (tape, dvd, external HDD) and rotate these monthly.
Don't forget to test restoration!
If you have 2 development servers, you should ideally build them identically with something like ubuntu preseed, or RHEL/Centos Kickstart. Then build the server environments with puppet. This will save you time in the long run, especially when you come to scale-out.
You could set up filesystem level replication with rsync between the multiple dev servers, but I'd personally recommend using a shared block-level storage system, like GlusterFS.
Get into the habit of writing unit tests early. Even if it's just for the core modules of your projects. Integrate these with a Unit Test runner, say PyUnit. Get a code-coverage analyser to help you develop effective tests.
Integrate your test environment with your Source Control with something like Hudson or Buildbot. Now you can get notified with which developer committed code that broke the build.
You should have a separate testing server, that mirrors your live environment. Ideally you have 2 of these, one in the office for local testing, and one in the same datacentre where your public servers are.
The reason for having 2 is that you can do rapid deployments and testing on the local one, but test the environment that is identical to the live servers, such as network differences, firewalls, routing, etc.
Once you have a few servers setup and working, you should consider some kind of centralised backup system. Backup all the important bits of your servers to a central location, and then replicate that data to a separate server. For example, one in the office, one in the datacentre.
As well as weekly offsite/offline backups, and Disaster recovery tests.
Again, a lot of this is the "ideal solution" and not financially viable for small startups. Investment in good practices early on does pay back in the future. Especially things which will limit the downtime when you're trying to scale rapidly.
Good source control and a productive development workflow goes a long way too.
