1

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...?

Schwern
  • 153,029
  • 25
  • 195
  • 336
NeuronQ
  • 7,527
  • 9
  • 42
  • 60
  • 1
    I didn't know that offensive words are allowed at SO. – Lajos Arpad Oct 01 '12 at 21:33
  • @Schwern ...sorry for that off topic rant at the end and for using the f word by habit. upon rereading my q I realized there was no point for that and thank you for editing it instead of just deleting or downvoting. cheers! – NeuronQ Oct 02 '12 at 07:42

2 Answers2

4

Would you rather look at a runtime where the paths and permissions are close to as they will be for-real so any errors might reflect reality, or would you like to spend your time running down oddball issues that will resolve to non-standard-deployment idiosyncracies? You know, things like

  • you're a local admin, so all resources are available to you, but when something gets deployed where the user account isn't an admin, it fails
  • path cruft that resolves fine locally but not in a deployed installation
  • that one new thing that didn't make it into [your|someone else's] check-in, so "It Works on My Machine!"(tm)

or any of a number of other things that slow things down but don't contribute to delivering quality code.

tl;dr: what @Schwern says below.

DaveE
  • 3,579
  • 28
  • 31
  • 1
    This can be summed up: make the dev/test installation as close to the production installation as possible, otherwise you're not testing the same thing as the users are using. Like you're working in a parallel universe. – Schwern Oct 01 '12 at 21:41
  • It makes sense if you actually have a testing server that's different from dev server hosting the main/central repo or any other flavor of a proper three stage setup with development-testing-production separate being 3 separate things... but what if the main repo is on the dev server and there's no separate testing server? (and I've seen this kind of set up...) – NeuronQ Oct 01 '12 at 22:34
  • You can, if absolutely necessary, have the repo on the server, but deploy it to a non-repo location for testing. Your repo should *not* be in your web server's deploy location. That'd just be dumb. – DaveE Oct 01 '12 at 22:40
  • @DaveE exactly, I know that "That'd just be dumb." is the "common knowledge", but really... WHY? (I don't care about security or stuff on the dev server and the repo is "clean", has only what it's supposed to have in it...) ...I actually care about this "way" because I like taking KISS philosophy to the extreme and questioning why every link in the chain is there and if it really has to be. this is a small dev set-up detail, I know, but small things like this that we do not question why add up and lead to complicated and unproductive workflows with tens of scripts for everyth like deployment – NeuronQ Oct 02 '12 at 07:49
  • 1
    It's dumb because you'd be **deliberately** testing in an environment that does not reflect a real deployment setup. It makes no logical sense to test in an environment that doesn't match, as closely as possible, your real-world deployment environment(s). You might as well call code done when it compiles in the developer environment, no integration or other functional tests needed. I'd hope any thinking developer would realise that _that_ scenario is a recipe for broken deliveries. If you're not testing _what the users will run_, you make your users your testers. – DaveE Oct 02 '12 at 18:10
2

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.

Schwern
  • 153,029
  • 25
  • 195
  • 336
  • Thanks for the detailed answer! ...so I should definitely have a testing server/vm/setup and this way it doesn't matter if the dev setup is less-than-exact (and if I do "stupid" things like running from a repo in dev setup). It's funny that trying to understand what the simplest solution could be, actually helped me understand why more "complex" setups like continuous integration testing exist and why they could really help :) – NeuronQ Oct 03 '12 at 09:02