views:

713

answers:

2

I have learned that builds should be very straight forward and requires less human intervention. In my situation, I have 3 environments, DEV (development version), SIT (STG integration testing) and UAT (user acceptance testing). All these environments have different database connection details and other settings (such as logging).

Currently when application needs to be deployed to SIT environment, what I need to do is to build the application. Install it on the target environment and modify the configuration file by hand. This is problematic as I may miss some entries. Things will get worse when configuration file is huge.

Questions

1 - Is there anyway to specify the environment name when making a build from VS. So that the configuration file for that environment will be used.

2 - What are the other methods which will help to reduce human intervention in builds?

3 - Assume my applications name is "Foo". I have a package project in the solution which will create installable package. Is there anyway to specify the product title depending upon the environment? I mean if SIT is selected, product name when installing will be "Foo-SIT". I guess this will avoid confusion of what environment version one is installing. I would be happy to hear any better alternatives if there are any.

+1  A: 

One way to handle this is to create 3 projects and put the environment in the name of the new projects. Then use a post-build event to copy the correct files based on the project name.

Inside the post build event you can tell the project name based on the $(ProjectName) macro. So you can do things like

IF "$(ProjectName)"="devproject" (
   copy ...
   copy ...
)

It's best to make these projects defer most of the real work (compilation) to a single project so that you don't have to keep settings up to date across multiple projects.

Arnshea
+1  A: 

2 -- You're absolutely right -- you should attempt to automate your build and deployment process as much as possible. Your best bet is to set up an automated build / deploy script using something like NAnt. Your script can have targets for each of your environments, e.g.

<project name="MyApp" xmlns="http://nant.sf.net/release/0.85/nant.xsd"&gt;
    <target name="DEV">
      <!-- execute any tasks needed to build the app, such as msbuild(1) -->

      <!-- execute any tasks needed to build the tweak the config files, such as xmlpeek / xmlpoke(2) -->

      <!-- execute any tasks needed to copy the now-built and configured project output the tweak the destination server, such as copy(3)-->
    </target>

    <target name="SIT">...</target>
    <target name="UAT">...</target>

</project>

If you're not familiar with NAnt, it should take you less than a day to get up and running and writing scripts. The payoff is immediate and long-lasting, as you'll never have to VNC onto a server and tweak configuration files ever again.

Jeremy Frey