Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

not sure if this is ok for this site, but here goes!

Looking for a skilled/experienced linux sysadmin that i can talk to about setting up a development environment for remote people to use for a project. (or if someone can point me to a good website/articles)

i've got 10-15 servers that i want to setup to be a development environment for creation of a couple of apps/projects. i envision that i'll have test/backup/user directory/production/app servers/etc...

i'm looking to talk (phone/email) with someone on the best approach to get this thing together.. want to also make sure that the system is secured as possible as the devs on the project will be remotely logging in. this is for a project that might turn into an open source project, but i don't want to use sourceforge and just hang the project out for everyone until it goes through a few iterations...

thanks in advance for any pointers/thoughts/etc...


share|improve this question
What does the test environment need to accomplish? – RussellBallestrini Feb 14 '10 at 23:14
hi again... thanks for the replies.. didn't find a spot on soln! we're looking to create a complete dev/test environment for not only webapps, but for our crawler as well.. so we need multiple "cheap" test client servers for the crawler, as well as the backup/test/dev, etc.. the proj mgmt app is meant to be the focal app for tracking information about a project, as well as dealing with the code for the given project... we're looking at gforge/track/dotproject/etc... to kind of figure out which we should explore.. – tom smith Feb 16 '10 at 14:17

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.

share|improve this answer

Do you really need that many servers for "a couple of apps/projects"? That seems waay overkill to me.
To give a little perspective, I work for a company with about 130 employees, and I look after 11 servers.

One thing is for sure, you'd be wise setting up your favourite version control server very early on in the process.

share|improve this answer
+1 for version control – Mark Henderson Feb 15 '10 at 1:37

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.