Which is more important in a web application code promotion hierarchy? production environment to repo resemblance or unidirectional propagation?

Question

Lets say you have a code promotion hierarchy consisting of several environments, (the polar end) two of which are development (dev) and production (prod).

Lets say you also have a web application where important (but not developer controlled) files are created (and perhaps altered) in the production environment.

Lets say that you (or someone above you) decided that the files which are controlled/created/altered/deleted in the production environment needed to go into the repository.

Which of the following two sets of practice / approaches do you find best:

1. Committing these non-developed file modifications made in the production environment so that the repository resembles the production environment as closely and as often as possible.

2. Generally ignoring the non-developed production environment alterations, placing confidence in backups to restore the production environment should it be harmed, and keeping a resolution to avoid pushing developments through the promotion hierarchy in the reverse direction (avoiding pushing from prod to dev), only committing the files found in the production environment if they were absolutely necessary in other environments for development.

So, 1 or 2, and why?

PS - I am currently slightly biased toward maintaining production environment to repository resemblance (option 1), but I keep an open mind and would accept an answer supporting either.

Answer 1

If the application is creating its own files, separate from those the developers create, you are essentially talking about using your development source control as a backup system. There are no advantages over any other kind of backup system and you're allowing files to be edited by people who don't understand source control. This seems dangerous to me.

Now that doesn't mean that you shouldn't take a copy of these files every now and then and deploy them to dev, just to keep the systems in sync, so that your tests are a more valid reproduction of production. Just don't do that through source control and your normal build process. If you did then what would happen if you start a build and then the application edits a file that is then overwritten by the deployment?

Another option, of course, is to put them in their own source control and give bi-directional control to the application (in essence, use VCS as a database for your application). This way you can handle revision history and such without having it all mixed up with the developers' changes. DVCS would be good for this, so that you can make changes on one environment and then push them to another -- perhaps even have a content-test environment where you can make changes, test them, then push them to both production and the application-test environment.

Even if the files edited by the application are the same files edited by developers, and thus they need to be merged, if the files are binary and edited often, I'd have to think very hard about the consequences with respect to the size of my source control database.

If they were text then fair enough but, unless I was very sure of the people making changes, I would again want to use a DVCS and make sure the application commits to a clone of the database, just so that I can pull them to a developer's machine and check them before committing to the master build database.

Answer 2

I'll go with "Save early, save often." Or, in this case, "Commit early, commit often."

Your #1 approach seems sensible, provided you get the granularity right. In any coding context, check-ins are done when they makes sense. It may not make sense to create six new control revisions for minor spelling errors, in the name of near-real-time fidelity.

On the other hand, your #2 approach seems destined to fail, if for no other reason than it has the words "confidence in backups" in it. [shudder] It also seems to run afoul of the decision-maker's instincts to put these files into source control in the first place.

Answer 3

I would go with option 2.

Separation of concerns makes me think that features and functionality should be as independent of content as possible.

Also backups are for restoring an environment into a production state, ie a harddrive dies ect.. If the backup is the development environment (or even test/staging) and someone has committed a half baked feature.. you can not restore your production environment.