On Jan 28, 2009, at 10:01 AM, Mike Gaffney wrote:
We actually have a machine that is a perfect clone of the production
machine. The only difference is the passwords. We test all
deployments to it first. We call it staging. Having a staging has 2
benefits:
1) We can test our deployment scripts, migrations, etc on as close
as we can get to production.
2) If the production box dies, we have one that can take it's place
very quickly (change the database passwords/pointers and go).
We also have a demo box that is updated via capistrano whenever the
build passes.
Testing configuration / deployment is hard because you can assert
that the config is what you think it is, but that in no way proves
that it's actually working. It's like using mocks to build up
functionality against a mock library. At some point you actually
have to test against the real thing or you're just guessing.
Well, it's actually even trickier than that, because I'm not only
deploying one app to one machine, but am writing a library, which
could be used for any number of apps to any number of machines (which
certain assumptions - i.e. a unix machine with mysql, etc.)
I've tested it locally (and by that I mean, on a staging slice), but
when I fix a bug in the library without writing a test, there is
absolutely no regression ability going forward.
Looks like establishing the test harness will the most tricky thing.
As usual, writing the first test is the hardest.
Scott
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
