A more robust solution, Carl, is to use three levels of servers. You should
have a development server, a test server, and a production server as well as
your own development desktop.
The development, test, and production server should be identitical in every
way from OS and patch level to drive models, configuration, installed
applications and options, and everything in between.
Then you deploy from your desktop to the development server and complete
troubleshooting and development in that environment.
When going to the test server, you want to migrate the completed code from
the development server to the test server using the exact migration tools,
scripts, or procedures that you will use to migrate from test to production.
As a developer, you don't want to touch the test server directly other than
by triggering the migration mechanism. That way you know that when you
migrate from test to production you will get identical results as when you
migrate from development to test. In my environment, developers (rightfully
so) cannot migrate from test to production. That must be done by the
application owner or project sponsor or their designee. But even so, the
process that they trigger to perform the migration must be identical to the
process used to migrate from development to test.
Also, you will want to apply the same rules to your database servers,
similarly testing your database creation or change scripts.
In my current environment, we have set a value in the appSettings section of
machine.config to determine the environment such as <key="AppEnv"
value="Local"> or set value to "Development", "Test", "Production", as
appropriate, then testing that value using
System.Configuration.ConfigurationSettings.AppSettings["AppEnv"] to
determine the current environemnt.
Finally, in the web.config file for the application we set values to point
to web service URLs and database connection strings based on the application
environment, for instance: <key="connectionString-Development" value="data
source=myDevServer;initial catalog=MyDB;Integrated Security=SSPI;packet
size=4096"> and consume that value with code similar to:
if (System.Configuration.ConfigurationSettings.AppSettings["AppEnv"] !=
null)
{
// Get the environment; choices are Local, Development, Test, and
Production
appEnv =
(string)System.Configuration.ConfigurationSettings.AppSettings["AppEnv"];
// If the appropriate AppEnv SqlConnectionString exists in the
// web.config, get the connection string
if
(System.Configuration.ConfigurationSettings.AppSettings["SqlConnectionString"
+ "-" + appEnv] != null)
{
sqlConnectionString =
(string)(System.Configuration.ConfigurationSettings.AppSettings["SqlConnectionString"
+ appEnv]);
}
}
Hope this helps,
DalePres
MCAD, MCDBA, MCSE