Jaa

Deployment scripts and Machine names

  • Artikkeli

  • In a typical nightly build scenario involving a multi tier app, the deployment and test scripts running on one tier might need the machine name of the other tier.

  • Example:

  • To provision IIS account on SQL, the computer name of the web tier need to be passed to the scripts that will be run on the data tier.

  • Similarly to set the data base connection string in web config file, the data tier machine name is needed by the web tier machine.

    If the computer names are hard coded in the scripts it will not scale in the cases where we have a set of similar environments (development environment, testing environment and production environment) and we want the same scripts to run in different environments (with different machine names). It would be good to generalize the deployment and testing scripts in such a way that it works properly irrespective of the change in the virtual machine's computer name.                                                                                                                                                                                                                                                             In this post, I will explain one way of achieving the same for deployment. Before that, take a look at this post which talks about using MSDeploy web deployment tool to deploy web apps. MS Deploy takes care of passing the data tier name to the webconfig file and hence we don’t have to worry about running it on different environments. Here is an other alternate to solve the issue if you are not using MSDeploy:

  • Consider the deployment of a web app. Typically the web config file will be pointing to the data tier machine for SQL connection string. Since the machine name is hard coded in web config file, the same web config file cannot be deployed across environments. Hence, the Db connection string need to be set properly in the web config file as part of deployment. This can be achieved by the below steps:

  • Let's say we have an environment by name "Nightly". It has two virtual machines by name "Webserver" and "DbServer".
  • Have a simple program which will open a given file(arg0) and do a string.Replace of String 1( arg1) with String2( arg2). Lets call it ReplaceText.exe.

clip_image001

  • In the checked in version of Web.config file edit the DB connection string to some constant value, say "DBSERVERNAME".

clip_image002

  • Now in your deployment script copy the web.config file to "WebServer" VM along with other binaries.
  • Invoke ReplaceText.exe on Web.config file and pass the computer name of the "DBServer" virtual machine as an argument by using $(InternalComputerName_DBServer) macro.

In the below example, first all the binaries and config files are copied from build drop location to C:\IBuySpy folder. Then ReplaceText.exe is invoked with following parameters : target file ( Web.Config ), string to be replaced (DBSERVERNAME ) and replacement string ($(InternalComputerName_DBSERVERName) macro which will be expanded to the machine name of DBServer VM). Following that other scripts are invoked.

clip_image003

Few things to note :

  • Make sure the build agent service account has read permissions on the share in which ReplaceText.exe tool is present.
  • In the case of network isolated environments with a private domain controller, the VM s will be joined to the private domain. If the corp domain has IPSEC policies set, then the VMs from the private domain cant access the corp resources. Hence for the build agent service account to access the network share, the machine need to have IPSEC disabled. In the above case "ddrelqa" machine need to have IPSEC disabled.