How should code in version control be stored?

Developer friendly? so that programmer can quickly take the latest and able to run from his editor without doing many changes? (like config files pointing to dev DB..etc)


Should it be production friendly? source should be in a manner which is easy to deploy on production environment and when developer takes the latest, he should perform changes as per his development needs.

8 Answers 8


Why choose ? It should be both.

Your development environment should be configured so it's as easy as doing a checkout, open, build, run, debug (eg: no absolute path!). You can do that easily with compilation directives, configuration class + dependancy injection, or even tricks like the perso.config in ASP.NET

Your automated build script should be customized enought to take care of specific production configuration, clean up, packaging etc.

  • What is perso.config? A quick google hasn't helped me.
    – Tim Murphy
    Commented Sep 22, 2010 at 12:55
  • 1
    In .NET application configuration file, you can reference another application configuration file that when found, will override specified settings. So you can create a dev.config file that override things like connection strings and other stuff, and exclude it from repos.
    – user2567
    Commented Sep 22, 2010 at 13:28
  • 5
    +1 - developers should not think to get the correct source. Also production deployment should not happen directly from source control, but with properly built, tested and trackable pieces. This process should be fully automated.
    – user1249
    Commented May 24, 2012 at 8:27

When it's an open source project where people are expected to contribute, I'd certainly opt for developer friendly.

My biggest dislike about open source projects is that very rarely does the repository contain all the dependencies needed to build the code (sometimes for practical or legal reasons), but when they don't - some don't even bother to tell you what dependencies you need, or more importantly, which version of them you need. (and preferably where to get them from)

Sometimes you can spend over half a day fetching and compiling several other projects in order to build the project you're after.

Of course, this is really only relevant for development on Windows.

  • 1
    It bugs the hell out of me. You even find it on very well known OSS.
    – Tim Murphy
    Commented Sep 22, 2010 at 12:57
  • 1
    There are systems that alleviate that problem by automatically fetching dependencies. E.g. Apache Maven, Ivy or scons.
    – sleske
    Commented Nov 12, 2011 at 0:19

Both, but it depends on how frequent you make your production. For many customized application, deployments are done manually and locally. On the other hand, developer will constantly commit code, no matter how small or big the project is. In my opinion, I think it is more important to make sure the developer can use the version control correctly, hence make their life easier so they will have time to focus on the code rather than finding the way through the version control.

  • Production deployments should be a non-issue if you use a continuous deployment engine to build.
    – user1249
    Commented Nov 21, 2010 at 16:14

It should be production-friendly, otherwise it is problematic to maintain automated builds.

  • 8
    Why? An automated build script can make all necessary translations to restructure the source into a deployable form. Never bother people with something automation can solve. Commented Oct 10, 2010 at 15:33

I'm all for lowering friction so that it's easier to get the job done, but you also need to take the failure modes into account.

If the source repository version is always configured for production use, what's the outcome of a developer failing to reconfigure before running the system? A developer running code against production.

Regardless of whether there are other hurdles in the way of the developer making random changes to production, building in a failure mode that encourages it to happen seems dangerous.

I suggest that the default values included in committed code should always be safe. Check the production configuration files into source control too, if you like - I almost always do - but keep them somewhere "not live".


I tend to strive for production-friendly. It keeps your builds clean and prevents extraneous settings from making it into production.


Definitely developer friendly, with scripts to automate changes for QA & production.


Why not to have a branch (depending of what version control you use - I use Git) for the deployable code and other for the developer ready version? This sounds much better and isn't that hard to setup.

You can work and commit your changes and then merge them on the deployable version.

  • Because long lived branches are expensive to manage and tend to be difficult to merge. You'd have to remember to make all the changes on both branches. Much better to make both versions the same and/or have a script to generate the deployable artifcat from the developer ready code.
    – bdsl
    Commented Oct 26, 2016 at 22:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.