Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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)
or
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.
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.
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.
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.
It should be production-friendly, otherwise it is problematic to maintain automated builds.
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.
