19

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.

Improve this question
56

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.

Improve this answer
3
  • What is perso.config? A quick google hasn't helped me. – Tim Murphy Sep 22 '10 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 Sep 22 '10 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 May 24 '12 at 8:27
9

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.

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

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.

Improve this answer
1
  • Production deployments should be a non-issue if you use a continuous deployment engine to build. – user1249 Nov 21 '10 at 16:14
1

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

Improve this answer
1
  • 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. – Joeri Sebrechts Oct 10 '10 at 15:33
1

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

Improve this answer
0

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

Improve this answer
0

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

Improve this answer
-1

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.

Improve this answer
1
  • 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 Oct 26 '16 at 22:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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