Here’s the problem:
Your application has numerous config files, and the values in these config files differ on every server or every environment. You hate manually updating the values every time you deploy your applications to a new environment, because that takes up too much of your time and inevitably leads to costly mistakes.
Here’s the solution:
Automate it.
And here’s one way of doing it:
- Use “master” config files that have ALL environmental details replaced with tokens
- Move copies of these files to folders denoting the environments they’ll be deployed to
- Use a token replacement operation to replace the tokens
- Deploy over the top of your code deployments, in doing so replacing the default config files
All the above can be automated very easily, and here’s how:
First off, make tokenised copies of your config files, so that environmental values are replaced with tokens, e.g.
change things like:
<add key=”DB:Connection” value=”Server=TestServer;Initial Catalog=TestDB;User id=Adminuser;password=pa55w0rd”/ >
to
<add key=”DB:Connection” value=”Server=%DB_SERVER%;Initial Catalog=%DB_NAME%;User id=%DB_UID%;password=%DB_PWD%”/ >
Then save a copy of these tokens, and their associated values in a sed file. This sed file should contain values specific to one environment, so that you’ll end up with 1 sed file per environment. These files act as lookups for the tokens and their values.
The sybntax for these sed files is:
s/%TOKEN%/TokenValue/i
So here’s the contents of a test environmemt sed file (testing.sed)
s/%DB_SERVER%/TestServer/i
s/%DB_NAME%/TestDB/i
s/%DB_UID%/Adminuser/i
s/%DB_PWD%/pa55w0rd/i
And here’s live.sed:
s/%DB_SERVER%/LiveServer/i
s/%DB_NAME%/LiveDB/i
s/%DB_UID%/Adminuser/i
s/%DB_PWD%/Livepa55w0rd/i
Next up, we want to have a section in our build script which renames the web_master.config files and copies them, and then runs the token replacement task….so here it is:
<target name=”moveconfigs” description=”renames configs, copies them to respective prep locations”>
<delete file=”${channel.dir}\web.config” verbose=”true” if=”${file::exists (webconfig)}” />
<move file=”${channel.dir}\web_Master.config” tofile=”${channel.dir}\web.config” if=”${file::exists (webMasterConfig)}” />
<delete file=”${channel.dir}\web.config” verbose=”true” if=”${file::exists (webconfig)}” />
<move file=”${channel.dir}\web_Master.config” tofile=”${channel.dir}\web.config” if=”${file::exists (webMasterConfig)}” />
<mkdir dir=”${build.ID.dir}\configs\TestArea” />
<mkdir dir=”${build.ID.dir}\configs\Live” />
<copy todir=”${build.ID.dir}\configs\TestArea\${channel.output.name}” >
<fileset basedir=”${channel.dir}” >
<include name=”**\*.config” />
<exclude name=”*.bak” />
</fileset>
</copy>
<copy todir=”${build.ID.dir}\configs\Live\${channel.output.name}” >
<fileset basedir=”${channel.dir}” >
<include name=”**\*.config” />
<exclude name=”*.bak” />
</fileset>
</copy>
</target>
<target name=”EditConfigs” description=”runs the token replacement by calling the sed script and passing the location of the tokenised configs as a parameter” >
<exec program=”D:\compiled\call_testarea.cmd” commandline=”${build.ID.dir}” />
<exec program=”D:\compiled\call_Live.cmd” commandline=”${build.ID.dir}” />
</target>
As you can see, the last target calls a couple of cmd files, the first of which looks like this:
xfind “%*\TestArea” -iname *.* xargs sed -i -f “D:\compiled\config\testing.sed”
xfind “%*\TestArea” -iname *.* xargs sed -i s/$/\r/
This is the sed command to read the config file, pipe the contents to sed and run the script file against it, and edit it in place. the second line handles Line Feeds so that the file ends up in a readable state. Essentially we’re telling sed to recursively read through the config file, and replace the tokens with the relevant value.
The advantage that this method has over using Nant’s “replacetokens” is that we can call the script for any number of files in any number of subdirectories using just one call, and the fact that the tokens and values are extracted from the build script. Also, the syntax means that the sed files are a lot smaller than a similar functioning Nant script would be.
Of course, you could make this whole thing even more elegant by putting the token/value pairs in a database instead of in a sed file, simply pull them out of the db at build/deploy time and then do the substitution.
People sometimes say that this method doesn’t work well if there are a large number of config files; they don’t like the idea of maintaining a large number of “master” versions as well as standard code versions. So to get around this, you can just not use tokens, but instead have the sed/replace look for the xml node and then the element, and simply replace the value there. There are plenty of ways of doing this using xml xPath. Both approaches have their own advantages, I guess the decision of which one to go for could just be a matter of how numerous your config files are.
Truly when someone doesn’t be aware of after that its up to other people that they will help, so here it occurs.
In just about every of those situation, which the sink is often transparent.
This, offer the whole family a present which they will enjoy this entire year and annum for a long time to follow.
That has been which that includes consisting of Sony psp Mixer, those ridiculous discounts, moved out with great.
All of this portion of food processor will not request bitter.
You’ll get free of the fish brand along with vary depending strictly against your Ninja 1100 Food processor alternatively.