Question

In a development/testing setup for a web application, when using a dvcs (bzr, git) why would it be wrong to actually run the application from the repository directory?

All the teams I’ve encountered have a separate deployment script that exports the repository checkout to another dir or server but I really never understood why and was afraid to ask the “grown up” not to seem “stupid”… I mean, it’s a development server anyway, not the production, so…?

Answer 1

To clarify, the issue isn’t really about how you deploy, that’s a whole other question. The deeper principle is that your test environment should be as close to production as possible for the reasons @DaveE mentioned: small deployment differences can make your tests useless.

It really sounds like you think mirroring the production install is too much work for your testing while developing. There’s two solutions to that. Making your test environment differ from production is not one of them.

First, make the production install easier. This could be turning a manual process (copy files here, run these scripts, change these permissions…) into an automated process. Or it could be actually cutting down what deployment does. Can’t say more without knowing the details.

If you don’t have a test environment, your dev environment becomes your test environment and must follow the stricter rules of being your only line of defense before production. To avoid that, create a staging server to test on. A staging server is one which mirrors production in as many was as possible. Development copies are installed on the staging server first and tested before being pushed to production. This gives you a two stage test system. You do some testing in your less-than-exact development environment, and the full battery of tests is done in the staging environment. The full test suite doesn’t have to be run all the time, so the staging server doesn’t have to constantly be updated. YMMV. You can then cut corners on your dev environment to speed up development while still knowing that everything will get tested on a full installation before production.

If you have the resources, a staging server is a perfect mirror of all the hardware and software in production. You probably don’t have that, so it can be a virtual machine or just a sub-directory. Both can live on your development machine if you don’t have buy in from the rest of the team.

Automating the install process, plus a staging server, means you can start doing continuous integration testing. This is a fancy term for “automatically run the tests on a test server on every commit”. An example of a continuous integration system is Jenkins. Then it doesn’t matter how complicated your deployment is, your robots take care of it for you.

So while it might seem like a lot of fussy work at first, it all comes together in the end to allow testing without you even pushing a button.

Ultimately your new code must be tested in an environment as similar as production as possible before being pushed live. There’s many ways to accomplish that, but that is a rock solid rule.