Should code in source control be in production or dev mode

[max105]

We're currently using VSS as our source control repository. All of our code in VSS are checked-in with the development flag turned on. Obviously, we have to remember to turn that flag off everytime we deploy code to production. I could see it making development easier since every time I get latest the code will already be in development mode.

Is it better to turn the development flags off by default in VSS to make code deployments easier? Or is it better to leave development flags on and turn them off when we deploy? I'm already leaning one way but I just wanted to get other people's opinions and thoughts.

 

[Crusty]

I use the App.config files for this, my 'release' branch simply has a different App.config file than the trunk which points the app to the production database, uses a different logging setup, etc.

Although, you didn't say you were using .NET, so this only applies there.

 

[Cogman]

This all depends on how often you are pushing new versions/updating. If you are just starting a product and don't see a release for a couple of months, then dev mode is best. If your product is released and you are doing something like weekly updates, then production mode is probably best.

 

[max105]

We're a ColdFusion shop. I suppose it's possible we could create a branch too for our purposes. Is this how it's normally done at other companies?

 

[max105]

This all depends on how often you are pushing new versions/updating. If you are just starting a product and don't see a release for a couple of months, then dev mode is best. If your product is released and you are doing something like weekly updates, then production mode is probably best.

No, this is our "legacy" product that's been around for probably 5-6 years. Since this is a customer facing app, we can sometimes go through a couple releases the same week if there's a client demand. Otherwise, we probably do bi-weekly releases if we follow our own schedule.

 

[Markbnj]

We use build configurations for this. Each build configuration has a post-build step that copies/renames the .config files for the debug (local dev), dev (dev server), test, and release environments.

 

[DaveSimmons]

We also use build configurations for this, for Visual Studio / C++. Most apps just have Release and Debug builds but one has four different sets of Release / Debug configurations with different preprocessor defines for C++ and the resource file.

 

[max105]

It sounds like I should just have config/build files take care of the final prod/dev mode of the application.

Even if you have config files for your build processes to manage the final application state, what is the default state when your code is in source control? Are these config files stored in source control?

 

[Markbnj]

It sounds like I should just have config/build files take care of the final prod/dev mode of the application.

Even if you have config files for your build processes to manage the final application state, what is the default state when your code is in source control? Are these config files stored in source control?

The "default state" would be whatever build configuration was selected when the .sln file was last checked in. In practice that is always "debug" for developers working on code locally, and since we build out to our dev, test, and production servers using cruise control it just selects the proper build configuration that it needs for a given environment. Works pretty well.

 

[Noriaki]

usually we try to keep trunk/master in a state that's "mostly functional" as in ready to hit an acceptance test and then have release branches/tags.

Once trunk/master passes an acceptance test, you merge to your release branch.

So, short answer: both

 

[Noriaki]

sounds like you're doing releases often enough that you might not have a full formal acceptance test process, I still suggest having specific branches to release from and don't release directly from trunk.

I have never actually used VSS, so I don't know how well branching and merging works in it though.

 

[Leros]

You work in a development branch, eventually getting into production quality. Then you copy it into another branch. That branch never gets changed, unless you're pushing updates for old version.