• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Should code in source control be in production or dev mode

M

max105

n00b
Joined
Feb 26, 2006
Messages
36
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.
 
It wildly depends on what you do....

We use both methods for different projects. I personally check in my dev code and than build offhand production version when dev builds pass QA.
 
Well, what is done more often with code pulled from VSS, is it worked on, or is it deployed? If someone gets the latest version 100x more often than someone does for a deployment, it wouldn't make a whole lot of sense to make it default release mode, that should be the responsibility of the person deploying.

And get rid of VSS already, sheesh.
 
mikeblas said:
VSS is junk. Get rid of it.
Click to expand...

This. It's based on the "jet" database, same one as used for old versions of Access. It's really not a good idea to use that for anything... at all. Try TFS or get something like perforce.
 
Pushing the concepts of branching and merging aside... I'd recommend not using the "development" flag. And based on what little that has been shared about the OP's needs, I think a simple "label" would be a better indicator.

Additionally, you're going to want to make sure that code promotions are never hopping over environments. If a build passes Dev, then promote that specific build to QA. If it passes QA, then promote that specific build to Prod. Don't have a build pass inspection in one environment, and not push those exact same files to the next environment.


*edit*
Personally, I don't care for VSS. TFS is a better step forward, but still is extremely hampered by some poor logic with their Visual Studio hooks/integration. If at all possible, get off of VSS now while you can still read your code trunks. TFS, Subversion, and Git are all better alternatives.
 
Last edited:
First, I'm with all of you on the VSS stance...I don't care for it either. Unfortunately, I don't get much of a say in these things. I'm still trying to get some people here to use source control properly. Also, certain people here are very happy that VSS integrates easily with Visual Studio that they will offer some resistance to change. I'll do some research on TFS though. People here are pro-MS so they'll be more likely to go for that.

We only have 2 developers on this project. I'm the primary developer and my "manager" is the backup. I do as many GET LATEST actions as I do deployments so it wouldn't bother me either way. It might bother the other developer if he has to get latest and change his code back to dev mode. I'm mostly concerned with upsetting this guy so I wanted to do some research/polling here first.

Our deployment process is completely manual and I would like to write a deployment script that pulls the latest version from VSS. The config file that controls the prod/dev flag is also checked into VSS. It's currently checked-in with dev mode but I'd like to change that to prod-mode. This way, I can deploy the latest version of code directly to production without having a middle step to change the dev/prod flags in the config file.
 
max105 said:
This way, I can deploy the latest version of code directly to production without having a middle step to change the dev/prod flags in the config file.
Click to expand...
Perhaps consider putting a Machine.Config (or some other key) in each environment that indicates what stage it is: Dev, QA, Prod, etc. Then your config files would store each environment's specifics, and just selectively load the needed config values based on the read-in environment key.
 
Last edited:
You must log in or register to reply here.
Back
Top