I’ve been working on my rails app which will be a web app that i want to
launch as a business. Being new to rails i’m wondering what
web app developers do for their development environment. Right now
developing and testing on my laptop. I think i’ve gotten far enough
where i want to put it up on a hosting machine to develop further,
test, and iterate. This is also so i can have other people test with
I’m in a similar position.
I don’t have any good advice about hosting services, but I do have some
suggestions about the dev/test/prod cycle and environments.
Fair warning- I got caught up in a train of thought so I’m afraid I
think I strayed from your question. My apologies.
I currently have a neat dev/test environment based around Xen:
I do development in a Xen virtual machine (based on an Ubuntu server
build). As I do development I track any Ubuntu package or ruby gem
dependencies so that these can be automatically installed in the
test/preproduction/production environments. Xen allows me to test the
build of my environment as well as the build of my code.
Life and work have distracted me from progressing these endeavours so it
isn’t complete but I’ll end up with a ‘shipping’ process that packages
up everything except the core application into Debian/Ubuntu packages
(so ruby gems etc… will probably be installed as packages) and puts
them in a private repository, installs them and then ships the core code
using something like swithtower. I can test the whole process using Xen
virtual machines. And I’ll install and test a ‘cluster’ of machines
(probably on the one “real” machine).
I’d install the core application as a Debian package too except the
ActiveRecord::Migration stuff is so damn convenient- and there is a lot
of Rails community development and support around switchtower and that
method of shipping code.
Most of this isn’t as laborious as it sounds since it all automates
The two main reasons for doing all this are:
- You should aim to never manually alter your production
environment- it should be built automatically so that it is repeatable.
This makes it testable which allows you to validate that you’ve actually
fixed problems when they arise. If you futz with the production
environment you’ll find yourself patching the system, forgetting what
you did and then having to debug the problem again six months down the
track when you lose a hard disk/reboot the system/delete the wrong
file/need to build a redundant system…
- It makes it much easier to build horizontally scalable systems.
[ Horizontally scalable means ‘add more machines to increase capacity’.
Vertically scalable means ‘add more CPUs/memory/spend lots more money’.
To make a good horizontally scalable system you do have to think
carefully about how you store your data and how you scale your data
store- but that is another discussion. ]
If you DO make a succesful application you want to make sure it will
scale and at that point you’ll really appreciate being able to create an
accurate production environment.
Another neat thing is that is very easy to create development
environments for other developers. They can each have their own virtual
machine and add test machines as required.
As a previous poster mentioned all your source code should be under
version control (probably subversion given the general Rails culture).
This code includes your Xen build scripts, testing infrastructure…
everything. If you are then careful about backing up your production
data stores (including your subversion system) you’ll find you can lose
production machines but be able to rebuild without any hassles. Or even
better you’ll have built everything clustered so you won’t even lose