Environment Agnosticism

[matthornsby]

Something I've been struggling with for awhile now is how to deploy applications through various environment without having to change the configuration. I always see database connection strings, names of environment-specific security groups, etc, placed inside an app.config or web.config file.

I'd love to have one web.config that never has to change when I migrate between environments, but so far I have yet to come up with a great solution.  I've considered use of environment variables, registry entries, and modifications to machine.config for web applications.  

For thick-client apps that get deployed to a desktop, it becomes even more tricky.

Have any of you solved this, and if so, how?  Using an auto-deploy script that builds/modifies the configuration based upon the environment isn't totally out of the question.

Thanks!
Matt

[Geoff Lehr]

Hey,

Basically, we put everything that doesn't change by environment into
the main config file, be it web.config or app.config, and have
separate config files that we reference for the things that do change,
eg "dev.appsettings.config", "test.appsettings.config" etc. Then our
deployment builds update the main config file to point to the correct
environment config.

It's not perfect, but it works pretty well most of the time.

Geoff

On Fri, Aug 28, 2009 at 12:20 PM, matthornsby2004<matt.hornsby@...> wrote:

>
>
> Something I've been struggling with for awhile now is how to deploy
> applications through various environment without having to change the
> configuration. I always see database connection strings, names of
> environment-specific security groups, etc, placed inside an app.config or
> web.config file.
>
> I'd love to have one web.config that never has to change when I migrate
> between environments, but so far I have yet to come up with a great
> solution. I've considered use of environment variables, registry entries,
> and modifications to machine.config for web applications.
>
> For thick-client apps that get deployed to a desktop, it becomes even more
> tricky.
>
> Have any of you solved this, and if so, how? Using an auto-deploy script
> that builds/modifies the configuration based upon the environment isn't
> totally out of the question.
>
> Thanks!
> Matt
>
>

[Paul Cowan-7]

I keep the seperate configuration details in a different xml file for
example:

<client name="demo1" displayname="demo1" environment="demo">
    <pageTitle>DEMO1</pageTitle>
    <connectionstring>Server=blah</connectionstring>
     <url>http://demo1.continuity2.com/</url>
</client>
I use rake to do my builds and I pass in a switch that specifies the client:

rake runtests=false client=demo1

I then update the web.config using the REXML ruby library although you could
use <xmlpoke> with nant or any xml library really.

I also update my windsor.boo file using regular expressions.

I think this is preferable to multiple different .config files.

Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/



2009/8/28 Geoff Lehr <geoff.lehr@...>

>
>
> Hey,
>
> Basically, we put everything that doesn't change by environment into
> the main config file, be it web.config or app.config, and have
> separate config files that we reference for the things that do change,
> eg "dev.appsettings.config", "test.appsettings.config" etc. Then our
> deployment builds update the main config file to point to the correct
> environment config.
>
> It's not perfect, but it works pretty well most of the time.
>
> Geoff
>
> On Fri, Aug 28, 2009 at 12:20 PM, matthornsby2004<matt.hornsby@...<matt.hornsby%40gmail.com>>
> wrote:
> >
> >
> > Something I've been struggling with for awhile now is how to deploy
> > applications through various environment without having to change the
> > configuration. I always see database connection strings, names of
> > environment-specific security groups, etc, placed inside an app.config or
> > web.config file.
> >
> > I'd love to have one web.config that never has to change when I migrate
> > between environments, but so far I have yet to come up with a great
> > solution. I've considered use of environment variables, registry entries,
> > and modifications to machine.config for web applications.
> >
> > For thick-client apps that get deployed to a desktop, it becomes even
> more
> > tricky.
> >
> > Have any of you solved this, and if so, how? Using an auto-deploy script
> > that builds/modifies the configuration based upon the environment isn't
> > totally out of the question.
> >
> > Thanks!
> > Matt
> >
> >
>
>

[bill barry]

We only have web applications and services that work with these
applications (no client machine software other than web pages), but...

We use a centralized database which has mirrors and uses the location
and machine name to figure out what database to connect to.

Using the location (website address + virtual directory name) and the
machine name we are able to determine which configuration is running
which tells us our connection string and various other bits of info we
need for any given web application. For services we use the working
directory for the location combined with the machine name.

This gives us the advantage of being able to run reports and see at any
given time what resources our clients are allocated and what clients are
allocated to any given resource. Our reporting tools also know these
identifiers and we can use them to figure out how much any client is
using any resource.
matthornsby2004 wrote:

> Something I've been struggling with for awhile now is how to deploy applications through various environment without having to change the configuration. I always see database connection strings, names of environment-specific security groups, etc, placed inside an app.config or web.config file.
>
> I'd love to have one web.config that never has to change when I migrate between environments, but so far I have yet to come up with a great solution.  I've considered use of environment variables, registry entries, and modifications to machine.config for web applications.  
>
> For thick-client apps that get deployed to a desktop, it becomes even more tricky.
>
> Have any of you solved this, and if so, how?  Using an auto-deploy script that builds/modifies the configuration based upon the environment isn't totally out of the question.
>
> Thanks!
> Matt
>  

[matthornsby]

Hi Bill,

I had considered the idea of a central "well-known" location to store this configuration information.  So you point to this same central configuration server across every environment, correct?

The only downside I see besides a potential single point of failure, which could be mitigated by mirroring, etc like you suggest, is that this central configuration database would be considered a production system and so it would be difficult to monkey around with the values stored there when testing in a dev or UAT environment.

Have you found that to be an issue?

Thanks,
Matt

--- In altdotnet@..., Bill Barry <after.fallout@...> wrote:

>
> We only have web applications and services that work with these
> applications (no client machine software other than web pages), but...
>
> We use a centralized database which has mirrors and uses the location
> and machine name to figure out what database to connect to.
>
> Using the location (website address + virtual directory name) and the
> machine name we are able to determine which configuration is running
> which tells us our connection string and various other bits of info we
> need for any given web application. For services we use the working
> directory for the location combined with the machine name.
>
> This gives us the advantage of being able to run reports and see at any
> given time what resources our clients are allocated and what clients are
> allocated to any given resource. Our reporting tools also know these
> identifiers and we can use them to figure out how much any client is
> using any resource.
> matthornsby2004 wrote:
> > Something I've been struggling with for awhile now is how to deploy applications through various environment without having to change the configuration. I always see database connection strings, names of environment-specific security groups, etc, placed inside an app.config or web.config file.
> >
> > I'd love to have one web.config that never has to change when I migrate between environments, but so far I have yet to come up with a great solution.  I've considered use of environment variables, registry entries, and modifications to machine.config for web applications.  
> >
> > For thick-client apps that get deployed to a desktop, it becomes even more tricky.
> >
> > Have any of you solved this, and if so, how?  Using an auto-deploy script that builds/modifies the configuration based upon the environment isn't totally out of the question.
> >
> > Thanks!
> > Matt
> >
>

[simone_b]

What I've come up with recently is to rely on an IoC container to do most of
the work.
That is, I still rely on the build process to produce a configuration file
for a specific environment, but in the configuration file I try to put a
single setting, which is the name of the environment.

The other settings are placed in classes, for example:

class DatabaseSettings
{
    string ConnectionString;
    TimeSpan CacheTimeout;
}

on which other components depend:

class Repository
{
    public Repository(DatabaseSettings settings) { ... }
}

I register several instances of the settings class into the container, and
instruct it somehow that a specific instance is suited for a specific
environment, using attributes, for example:

container.AddInstance(new DatabaseSettings { ConnectionString = "...",
CacheTimeout = ... }).ForDevelopment();
container.AddInstance(new DatabaseSettings { ConnectionString = "...",
CacheTimeout = ... }).ForProduction();

then I have my configuration file which contains just one setting:

<appSettings>
    <add key="environment" value="development" />
</appSettings>

The container is then configured in a way that it is able to understand
which instance of settings to provide to components which depend on it
according to the current environment.


On Fri, Aug 28, 2009 at 22:36, matthornsby2004 <matt.hornsby@...>wrote:

>
>
> Hi Bill,
>
> I had considered the idea of a central "well-known" location to store this
> configuration information. So you point to this same central configuration
> server across every environment, correct?
>
> The only downside I see besides a potential single point of failure, which
> could be mitigated by mirroring, etc like you suggest, is that this central
> configuration database would be considered a production system and so it
> would be difficult to monkey around with the values stored there when
> testing in a dev or UAT environment.
>
> Have you found that to be an issue?
>
> Thanks,
> Matt
>
>
> --- In altdotnet@... <altdotnet%40yahoogroups.com>, Bill Barry
> <after.fallout@...> wrote:
> >
> > We only have web applications and services that work with these
> > applications (no client machine software other than web pages), but...
> >
> > We use a centralized database which has mirrors and uses the location
> > and machine name to figure out what database to connect to.
> >
> > Using the location (website address + virtual directory name) and the
> > machine name we are able to determine which configuration is running
> > which tells us our connection string and various other bits of info we
> > need for any given web application. For services we use the working
> > directory for the location combined with the machine name.
> >
> > This gives us the advantage of being able to run reports and see at any
> > given time what resources our clients are allocated and what clients are
> > allocated to any given resource. Our reporting tools also know these
> > identifiers and we can use them to figure out how much any client is
> > using any resource.
> > matthornsby2004 wrote:
> > > Something I've been struggling with for awhile now is how to deploy
> applications through various environment without having to change the
> configuration. I always see database connection strings, names of
> environment-specific security groups, etc, placed inside an app.config or
> web.config file.
> > >
> > > I'd love to have one web.config that never has to change when I migrate
> between environments, but so far I have yet to come up with a great
> solution. I've considered use of environment variables, registry entries,
> and modifications to machine.config for web applications.
> > >
> > > For thick-client apps that get deployed to a desktop, it becomes even
> more tricky.
> > >
> > > Have any of you solved this, and if so, how? Using an auto-deploy
> script that builds/modifies the configuration based upon the environment
> isn't totally out of the question.
> > >
> > > Thanks!
> > > Matt
> > >
> >
>
>  
>

[Bryan Murphy-4]

On Fri, Aug 28, 2009 at 1:20 PM, matthornsby2004 <matt.hornsby@...>wrote:

> I'd love to have one web.config that never has to change when I migrate
> between environments, but so far I have yet to come up with a great
> solution.  I've considered use of environment variables, registry entries,
> and modifications to machine.config for web applications.
>

We built our own configuration system based off of xml files.  It works like
this:

Given the following folder structure:

Config\Default\Tools.config
Config\Developmen\Tools.config
Config\Linux\Tools.config
Config\Production\Tools.config
Config\Staging\Tools.config
Config\Windows\Tools.config.xslt
etc.

And the following profile:

<Profile>
  <Name>Production Environment</Name>
  <Profiles>
    <Profile>Default</Profile>
    <Profile>Linux</Profile>
    <Profile>Production</Profile>
  </Profiles>
  <Substitutions>
    <Substitution Name="LogPath">C:\Logs</Substitution>
    <Substitution
Name="DeployPath">C:\Deploy\Production\Version#</Substitution>
  </Substitutions>
</Profile>

And the following line of code:

var config = configService.Load<ToolsConfig>("Tools.config");

We have a primitive patching mechanism that effectively implements xml file
inheritance. We load Default\Tools.config, then patch it with the contents
of Linux\Tools.config, and then patch it with the conents of
Production\Tools.config.

The patching is very simple (replace if node exists, insert if node does not
exist).  For more complex modifications, we can use an XSL transformation
instead (see the last directory entry).

After the transformation is done, we have one more pass that takes the
inherited xml document and processes all text nodes, replacing references
such as ${{LogPath}} and ${{DeployPath}} with the appropriate values from
the profile.

Finally, we usually feed the output of this transformation into
XmlSerializer.

We have the ability to do this at runtime or we can pre-compile the files.
The profile configuration can either be passed to the application, or
deployed to a known location relative to the application.

The amount of configuration in one of our "Production" folders is typically
very minimal, consisting of nothing more than a few IP addresses, DNS names,
and minor stuff like that.  The majority of the configuration is in on of
the base folders, shared across multiple environments (including
development, and more importantly, our testing and staging environments).

This has worked out so well for us that we avoid putting configuration into
App.config or Web.config unless we absolutely have no choice but to do so.

Bryan

[bill barry]

We mitigate it by mirroring and we have separate ones for dev/testing
(the configuration db is set by build script in web.config). We haven't
had an issue with the single point of failure but a word of warning: one
mistake by a dba who doesn't understand what he is doing can bring the
whole thing down.
It would be just as easy and we have considered the idea of an xml file
that simply gets deserialized upon startup and searched with the same
parameters. Since our releases are versioned we could do this very
easily and ensure that each system has the latest configuration file.

matthornsby2004 wrote:

> Hi Bill,
>
> I had considered the idea of a central "well-known" location to store this configuration information.  So you point to this same central configuration server across every environment, correct?
>
> The only downside I see besides a potential single point of failure, which could be mitigated by mirroring, etc like you suggest, is that this central configuration database would be considered a production system and so it would be difficult to monkey around with the values stored there when testing in a dev or UAT environment.
>
> Have you found that to be an issue?
>
> Thanks,
> Matt
>
> --- In altdotnet@..., Bill Barry <after.fallout@...> wrote:
>  
>> We only have web applications and services that work with these
>> applications (no client machine software other than web pages), but...
>>
>> We use a centralized database which has mirrors and uses the location
>> and machine name to figure out what database to connect to.
>>
>> Using the location (website address + virtual directory name) and the
>> machine name we are able to determine which configuration is running
>> which tells us our connection string and various other bits of info we
>> need for any given web application. For services we use the working
>> directory for the location combined with the machine name.
>>
>> This gives us the advantage of being able to run reports and see at any
>> given time what resources our clients are allocated and what clients are
>> allocated to any given resource. Our reporting tools also know these
>> identifiers and we can use them to figure out how much any client is
>> using any resource.
>> matthornsby2004 wrote:
>>    
>>> Something I've been struggling with for awhile now is how to deploy applications through various environment without having to change the configuration. I always see database connection strings, names of environment-specific security groups, etc, placed inside an app.config or web.config file.
>>>
>>> I'd love to have one web.config that never has to change when I migrate between environments, but so far I have yet to come up with a great solution.  I've considered use of environment variables, registry entries, and modifications to machine.config for web applications.  
>>>
>>> For thick-client apps that get deployed to a desktop, it becomes even more tricky.
>>>
>>> Have any of you solved this, and if so, how?  Using an auto-deploy script that builds/modifies the configuration based upon the environment isn't totally out of the question.
>>>
>>> Thanks!
>>> Matt
>>>
>>>      
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>  

[Steven Campbell]

Late to the party here, but we have solved this very well for own custom
environment.  I'm surprised there is not a generic solution out there,
because the challenges are very common.

The main thing we realized is that a software application that has many
different target servers and configurations should have automated
single-step deployments.  We cannot be spending time on executing
deployments every time we need to do one.  Once we made that choice, the
rest fell into place over time (about 9 months from first attempt to
something that is pretty mature and easy to configure).  Over the last year,
we did about 1500 deployments this way.

If your environment is anything like ours then you can probably save some
time by making the second important choice we made - to move all
configuration settings into a file of our own design (xml in our case).  The
pain of designing our own file format was much less than the alternatives.

We have a single config file for all environments, because that allows us to
centrally manage ports, passwords etc.  YMMV on that one.

On our team, we still use normal app.config and web.config settings.  This
was our choice - during deployments we read the single config file, and
xmlpoke settings into web.config files etc.  We key off of client name +
environment, e.g. "Comcast" + "DEV" in order to find the right settings in
the file.

Other teams I know of prefer to read config settings at run-time, and they
use a centralized config server for that, and then cache it so there is less
of a risk of single point of failure.

On Fri, Aug 28, 2009 at 7:04 PM, Bill Barry <after.fallout@...> wrote:

>
>
> We mitigate it by mirroring and we have separate ones for dev/testing (the
> configuration db is set by build script in web.config). We haven't had an
> issue with the single point of failure but a word of warning: one mistake by
> a dba who doesn't understand what he is doing can bring the whole thing
> down.
> It would be just as easy and we have considered the idea of an xml file
> that simply gets deserialized upon startup and searched with the same
> parameters. Since our releases are versioned we could do this very easily
> and ensure that each system has the latest configuration file.
>
> matthornsby2004 wrote:
>
> Hi Bill,
>
> I had considered the idea of a central "well-known" location to store this configuration information.  So you point to this same central configuration server across every environment, correct?
>
> The only downside I see besides a potential single point of failure, which could be mitigated by mirroring, etc like you suggest, is that this central configuration database would be considered a production system and so it would be difficult to monkey around with the values stored there when testing in a dev or UAT environment.
>
> Have you found that to be an issue?
>
> Thanks,
> Matt
>
> --- In altdotnet@..., Bill Barry <after.fallout@...> <after.fallout@...> wrote:
>
>
>  We only have web applications and services that work with these
> applications (no client machine software other than web pages), but...
>
> We use a centralized database which has mirrors and uses the location
> and machine name to figure out what database to connect to.
>
> Using the location (website address + virtual directory name) and the
> machine name we are able to determine which configuration is running
> which tells us our connection string and various other bits of info we
> need for any given web application. For services we use the working
> directory for the location combined with the machine name.
>
> This gives us the advantage of being able to run reports and see at any
> given time what resources our clients are allocated and what clients are
> allocated to any given resource. Our reporting tools also know these
> identifiers and we can use them to figure out how much any client is
> using any resource.
> matthornsby2004 wrote:
>
>
>  Something I've been struggling with for awhile now is how to deploy applications through various environment without having to change the configuration. I always see database connection strings, names of environment-specific security groups, etc, placed inside an app.config or web.config file.
>
> I'd love to have one web.config that never has to change when I migrate between environments, but so far I have yet to come up with a great solution.  I've considered use of environment variables, registry entries, and modifications to machine.config for web applications.
>
> For thick-client apps that get deployed to a desktop, it becomes even more tricky.
>
> Have any of you solved this, and if so, how?  Using an auto-deploy script that builds/modifies the configuration based upon the environment isn't totally out of the question.
>
> Thanks!
> Matt
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
>  
>

--
Steve Campbell
http://blog.perfectapi.com/

[Steven Smith-23]

Same here.

On Fri, Aug 28, 2009 at 2:57 PM, Geoff Lehr <geoff.lehr@...> wrote:

>
>
> Hey,
>
> Basically, we put everything that doesn't change by environment into
> the main config file, be it web.config or app.config, and have
> separate config files that we reference for the things that do change,
> eg "dev.appsettings.config", "test.appsettings.config" etc. Then our
> deployment builds update the main config file to point to the correct
> environment config.
>
> It's not perfect, but it works pretty well most of the time.
>
> Geoff
>
>
> On Fri, Aug 28, 2009 at 12:20 PM, matthornsby2004<matt.hornsby@...<matt.hornsby%40gmail.com>>
> wrote:
> >
> >
> > Something I've been struggling with for awhile now is how to deploy
> > applications through various environment without having to change the
> > configuration. I always see database connection strings, names of
> > environment-specific security groups, etc, placed inside an app.config or
> > web.config file.
> >
> > I'd love to have one web.config that never has to change when I migrate
> > between environments, but so far I have yet to come up with a great
> > solution. I've considered use of environment variables, registry entries,
> > and modifications to machine.config for web applications.
> >
> > For thick-client apps that get deployed to a desktop, it becomes even
> more
> > tricky.
> >
> > Have any of you solved this, and if so, how? Using an auto-deploy script
> > that builds/modifies the configuration based upon the environment isn't
> > totally out of the question.
> >
> > Thanks!
> > Matt
> >
> >
>
>  
>

--
Steve Smith
http://SteveSmithBlog.com/
http://twitter.com/ardalis

[matthornsby]

Thanks everyone for your replies - I really appreciate you sharing your experience and the setups that you use.  

Steven, can you elaborate more on what you mean by "single-step deployments"?

Others seem to like the idea of having the build process maintain and decide which environment-specific settings to use and to then automatically create or modify a .config file.  My company is just now moving to automated builds, so I think this is something that may be a good choice for us once we get there.

I do like the idea of a centralized configuration server, but my company doesn't have one quite yet.  I may try to make a case for it going forward.

--- In altdotnet@..., Steven Campbell <dukeytoo@...> wrote:

>
> Late to the party here, but we have solved this very well for own custom
> environment.  I'm surprised there is not a generic solution out there,
> because the challenges are very common.
>
> The main thing we realized is that a software application that has many
> different target servers and configurations should have automated
> single-step deployments.  We cannot be spending time on executing
> deployments every time we need to do one.  Once we made that choice, the
> rest fell into place over time (about 9 months from first attempt to
> something that is pretty mature and easy to configure).  Over the last year,
> we did about 1500 deployments this way.
>
> If your environment is anything like ours then you can probably save some
> time by making the second important choice we made - to move all
> configuration settings into a file of our own design (xml in our case).  The
> pain of designing our own file format was much less than the alternatives.
>
> We have a single config file for all environments, because that allows us to
> centrally manage ports, passwords etc.  YMMV on that one.
>
> On our team, we still use normal app.config and web.config settings.  This
> was our choice - during deployments we read the single config file, and
> xmlpoke settings into web.config files etc.  We key off of client name +
> environment, e.g. "Comcast" + "DEV" in order to find the right settings in
> the file.
>
> Other teams I know of prefer to read config settings at run-time, and they
> use a centralized config server for that, and then cache it so there is less
> of a risk of single point of failure.
>

[matthornsby]

Hi Bryan,

Thanks for sharing - this is a very interesting idea.  Where are all the profiles stored?  Also, where is it decided which profile to use?  Do you have it defined somewhere that when you are deploying to say, Production, you use the "Production Environment"?

--- In altdotnet@..., Bryan Murphy <bmurphy1976@...> wrote:

>
> On Fri, Aug 28, 2009 at 1:20 PM, matthornsby2004 <matt.hornsby@...>wrote:
>
> > I'd love to have one web.config that never has to change when I migrate
> > between environments, but so far I have yet to come up with a great
> > solution.  I've considered use of environment variables, registry entries,
> > and modifications to machine.config for web applications.
> >
>
> We built our own configuration system based off of xml files.  It works like
> this:
>
> Given the following folder structure:
>
> Config\Default\Tools.config
> Config\Developmen\Tools.config
> Config\Linux\Tools.config
> Config\Production\Tools.config
> Config\Staging\Tools.config
> Config\Windows\Tools.config.xslt
> etc.
>
> And the following profile:
>
> <Profile>
>   <Name>Production Environment</Name>
>   <Profiles>
>     <Profile>Default</Profile>
>     <Profile>Linux</Profile>
>     <Profile>Production</Profile>
>   </Profiles>
>   <Substitutions>
>     <Substitution Name="LogPath">C:\Logs</Substitution>
>     <Substitution
> Name="DeployPath">C:\Deploy\Production\Version#</Substitution>
>   </Substitutions>
> </Profile>
>
> And the following line of code:
>
> var config = configService.Load<ToolsConfig>("Tools.config");
>
> We have a primitive patching mechanism that effectively implements xml file
> inheritance. We load Default\Tools.config, then patch it with the contents
> of Linux\Tools.config, and then patch it with the conents of
> Production\Tools.config.
>
> The patching is very simple (replace if node exists, insert if node does not
> exist).  For more complex modifications, we can use an XSL transformation
> instead (see the last directory entry).
>
> After the transformation is done, we have one more pass that takes the
> inherited xml document and processes all text nodes, replacing references
> such as ${{LogPath}} and ${{DeployPath}} with the appropriate values from
> the profile.
>
> Finally, we usually feed the output of this transformation into
> XmlSerializer.
>
> We have the ability to do this at runtime or we can pre-compile the files.
> The profile configuration can either be passed to the application, or
> deployed to a known location relative to the application.
>
> The amount of configuration in one of our "Production" folders is typically
> very minimal, consisting of nothing more than a few IP addresses, DNS names,
> and minor stuff like that.  The majority of the configuration is in on of
> the base folders, shared across multiple environments (including
> development, and more importantly, our testing and staging environments).
>
> This has worked out so well for us that we avoid putting configuration into
> App.config or Web.config unless we absolutely have no choice but to do so.
>
> Bryan
>

[Bryan Murphy-4]

We use NAnt scripts to create the profiles.  i.e.

nant createProfileForMainWebSiteProduction
nant createProfileForSecondaryWebSiteStaging
etc.

Creates the profile configs for the target application/environment, and
automatically wires up all the directory references relative to the folder
where we ran the command (which is also the folder we deploy to).

So, deployment looks like this:

checkout/branch/tag/etc.
nant buildMainWebSite
nant packageMainWebSite
copy to target servers
nant createProfileForMainWebSiteProduction
nant installMainWebSite

Bryan

On Thu, Sep 10, 2009 at 10:42 AM, matthornsby <matt.hornsby@...>wrote:

> Hi Bryan,
>
> Thanks for sharing - this is a very interesting idea.  Where are all the
> profiles stored?  Also, where is it decided which profile to use?  Do you
> have it defined somewhere that when you are deploying to say, Production,
> you use the "Production Environment"?
>
> --- In altdotnet@..., Bryan Murphy <bmurphy1976@...> wrote:
> >
> > On Fri, Aug 28, 2009 at 1:20 PM, matthornsby2004 <matt.hornsby@
> ...>wrote:
> >
> > > I'd love to have one web.config that never has to change when I migrate
> > > between environments, but so far I have yet to come up with a great
> > > solution.  I've considered use of environment variables, registry
> entries,
> > > and modifications to machine.config for web applications.
> > >
> >
> > We built our own configuration system based off of xml files.  It works
> like
> > this:
> >
> > Given the following folder structure:
> >
> > Config\Default\Tools.config
> > Config\Developmen\Tools.config
> > Config\Linux\Tools.config
> > Config\Production\Tools.config
> > Config\Staging\Tools.config
> > Config\Windows\Tools.config.xslt
> > etc.
> >
> > And the following profile:
> >
> > <Profile>
> >   <Name>Production Environment</Name>
> >   <Profiles>
> >     <Profile>Default</Profile>
> >     <Profile>Linux</Profile>
> >     <Profile>Production</Profile>
> >   </Profiles>
> >   <Substitutions>
> >     <Substitution Name="LogPath">C:\Logs</Substitution>
> >     <Substitution
> > Name="DeployPath">C:\Deploy\Production\Version#</Substitution>
> >   </Substitutions>
> > </Profile>
> >
> > And the following line of code:
> >
> > var config = configService.Load<ToolsConfig>("Tools.config");
> >
> > We have a primitive patching mechanism that effectively implements xml
> file
> > inheritance. We load Default\Tools.config, then patch it with the
> contents
> > of Linux\Tools.config, and then patch it with the conents of
> > Production\Tools.config.
> >
> > The patching is very simple (replace if node exists, insert if node does
> not
> > exist).  For more complex modifications, we can use an XSL transformation
> > instead (see the last directory entry).
> >
> > After the transformation is done, we have one more pass that takes the
> > inherited xml document and processes all text nodes, replacing references
> > such as ${{LogPath}} and ${{DeployPath}} with the appropriate values from
> > the profile.
> >
> > Finally, we usually feed the output of this transformation into
> > XmlSerializer.
> >
> > We have the ability to do this at runtime or we can pre-compile the
> files.
> > The profile configuration can either be passed to the application, or
> > deployed to a known location relative to the application.
> >
> > The amount of configuration in one of our "Production" folders is
> typically
> > very minimal, consisting of nothing more than a few IP addresses, DNS
> names,
> > and minor stuff like that.  The majority of the configuration is in on of
> > the base folders, shared across multiple environments (including
> > development, and more importantly, our testing and staging environments).
> >
> > This has worked out so well for us that we avoid putting configuration
> into
> > App.config or Web.config unless we absolutely have no choice but to do
> so.
> >
> > Bryan
> >
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Steven Campbell]

On Thu, Sep 10, 2009 at 10:37 AM, matthornsby <matt.hornsby@...> wrote:
>
> Thanks everyone for your replies - I really appreciate you sharing your experience and the setups that you use.
>
> Steven, can you elaborate more on what you mean by "single-step deployments"?
>

Maybe single-click would have been a better way to say it - there are
multiple steps, but they are all executed in a single deployment
script.  Exactly the same concept as a Windows setup.exe that can be
executed silently (setup.exe /s /d="c:\program files\myapp\" /etc) .

Once deployed, the environment is statically configured - changing
configuration requires a new deploy.

It is not really very different from Bryan's model.  His steps were:
checkout/branch/tag/etc.
nant buildMainWebSite
nant packageMainWebSite
copy to target servers
nant createProfileForMainWebSiteProduction
nant installMainWebSite

Ours are:
continuous integration compiles binaries, simple MSBuild stuff
nant deployEverything Client="XYZ" Environment="PROD"

[Michael J. Ryan-4]

I came up with a pretty cool solution to this last year, though haven't
revisited the logging piece since leaving Apollo Group.

http://www.codeplex.com/ApolloCommon

On 9/10/2009 6:04 AM, Steven Smith wrote:

>
>
> Same here.
>
>
> On Fri, Aug 28, 2009 at 2:57 PM, Geoff Lehr <geoff.lehr@...
> <mailto:geoff.lehr@...>> wrote:
>
>      
>
>     Hey,
>
>     Basically, we put everything that doesn't change by environment into
>     the main config file, be it web.config or app.config, and have
>     separate config files that we reference for the things that do change,
>     eg "dev.appsettings.config", "test.appsettings.config" etc. Then our
>     deployment builds update the main config file to point to the correct
>     environment config.
>
>     It's not perfect, but it works pretty well most of the time.
>
>     Geoff
>
>
>
>     On Fri, Aug 28, 2009 at 12:20 PM,
>     matthornsby2004<matt.hornsby@...
>     <mailto:matt.hornsby%40gmail.com>> wrote:
>      >
>      >
>      > Something I've been struggling with for awhile now is how to deploy
>      > applications through various environment without having to change the
>      > configuration. I always see database connection strings, names of
>      > environment-specific security groups, etc, placed inside an
>     app.config or
>      > web.config file.
>      >
>      > I'd love to have one web.config that never has to change when I
>     migrate
>      > between environments, but so far I have yet to come up with a great
>      > solution. I've considered use of environment variables, registry
>     entries,
>      > and modifications to machine.config for web applications.
>      >
>      > For thick-client apps that get deployed to a desktop, it becomes
>     even more
>      > tricky.
>      >
>      > Have any of you solved this, and if so, how? Using an auto-deploy
>     script
>      > that builds/modifies the configuration based upon the environment
>     isn't
>      > totally out of the question.
>      >
>      > Thanks!
>      > Matt
>      >
>      >
>
>
>
>
> --
> Steve Smith
> http://SteveSmithBlog.com/
> http://twitter.com/ardalis
>
>
>
>

--
Michael J. Ryan - http://tracker1.info/

... FRA #062: The riskier the road, the greater the profit.

[mcintyre321]

At my last job the settings were all hardcoded into the application with very very little xml configuration. The idea was that XML settings are only really needed if you are changing stuff on a particular environment once it is deployed. In the setup we had (a self hosted web app), by using conventions on the machine names (and other properties) it was possible to determine the machines role and then load an appropriate configuration class into IOC.

At first I thought it was mad, but after a while I found it pretty refreshing TBH.

matthornsby wrote:

Something I've been struggling with for awhile now is how to deploy applications through various environment without having to change the configuration. I always see database connection strings, names of environment-specific security groups, etc, placed inside an app.config or web.config file.

I'd love to have one web.config that never has to change when I migrate between environments, but so far I have yet to come up with a great solution.  I've considered use of environment variables, registry entries, and modifications to machine.config for web applications.  

For thick-client apps that get deployed to a desktop, it becomes even more tricky.

Have any of you solved this, and if so, how?  Using an auto-deploy script that builds/modifies the configuration based upon the environment isn't totally out of the question.

Thanks!
Matt

[Adam Dymitruk]

Just edit the host file on your dev machine, QA, and prod. You can use the
same config everywhere now using a name that will resolve to a different ip
in each area..
--
Adam

http://twitter.com/adymitruk/
http://www.agilevancouver.net/
http://altnetvancouver.ning.com/

[mcintyre321]

Config differences can be a lot more than just IPs between environments. Also, changing the hosts file means you have to update each machine when config changes.

Adam Dymitruk wrote:

Just edit the host file on your dev machine, QA, and prod. You can use the
same config everywhere now using a name that will resolve to a different ip
in each area..er
--
Adam

http://twitter.com/adymitruk/
http://www.agilevancouver.net/
http://altnetvancouver.ning.com/

[Adam Dymitruk]

> Config differences can be a lot more than just IPs between environments.
> Also, changing the hosts file means you have to update each machine when
> config changes.

config differences can be a lot more.. but they shouldn't if they
don't have to be

How would you have to change the host file every time the config file
changes? I haven't had to change the host files for a long time now...

--
Adam

http://adventuresinagile.blogspot.com/
http://twitter.com/adymitruk/
http://www.agilevancouver.net/
http://altnetvancouver.ning.com/

[Erick Thompson]

One of the things I like about the web deployment project is that it
allows you replace sections of your web.config file based on the build
type (debug/release). It seems like most build systems should be able to
handle this, as it's a simple XML load/modify/replace cycle. Is
something more needed?

 

Thanks,

Erick

 

 

From: altdotnet@... [mailto:altdotnet@...] On
Behalf Of Paul Cowan
Sent: Friday, August 28, 2009 12:07 PM
To: altdotnet@...
Subject: Re: [altdotnet] Environment Agnosticism

 

 

I keep the seperate configuration details in a different xml file for
example:

<

client name="demo1" displayname="demo1" environment="demo">
    <pageTitle>DEMO1</pageTitle>
    <connectionstring>Server=blah</connectionstring>
     <url>http://demo1.continuity2.com/</url>
</client>

I use rake to do my builds and I pass in a switch that specifies the
client:

 

rake runtests=false client=demo1

I then update the web.config using the REXML ruby library although you
could use <xmlpoke> with nant or any xml library really.

I also update my windsor.boo file using regular expressions.

I think this is preferable to multiple different .config files.

Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/




2009/8/28 Geoff Lehr <geoff.lehr@...>

 

Hey,

Basically, we put everything that doesn't change by environment into
the main config file, be it web.config or app.config, and have
separate config files that we reference for the things that do change,
eg "dev.appsettings.config", "test.appsettings.config" etc. Then our
deployment builds update the main config file to point to the correct
environment config.

It's not perfect, but it works pretty well most of the time.

Geoff

On Fri, Aug 28, 2009 at 12:20 PM, matthornsby2004<matt.hornsby@...
<mailto:matt.hornsby%40gmail.com> > wrote:
>
>
> Something I've been struggling with for awhile now is how to deploy
> applications through various environment without having to change the
> configuration. I always see database connection strings, names of
> environment-specific security groups, etc, placed inside an app.config
or
> web.config file.
>
> I'd love to have one web.config that never has to change when I
migrate
> between environments, but so far I have yet to come up with a great
> solution. I've considered use of environment variables, registry
entries,
> and modifications to machine.config for web applications.
>
> For thick-client apps that get deployed to a desktop, it becomes even
more
> tricky.
>
> Have any of you solved this, and if so, how? Using an auto-deploy
script
> that builds/modifies the configuration based upon the environment
isn't
> totally out of the question.
>
> Thanks!
> Matt
>
>

 





This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.  If you have received this e-mail in error please notify the NBR system manager.  If you are not the named addressee please notify the sender immediately by e-mail and please delete this e-mail from your system.  If you are not the intended recipient you are hereby notified that disclosing, copying, distributing, or taking any action in reliance on the contents of this information is strictly prohibited.

Warning: Although having taken reasonable precautions to ensure no viruses are present in this e-mail, The National Bureau of Asian Research cannot accept responsibility for any loss or damage arising from the use of this e-mail or attachments.