Deploying services
Today we finished a first version of our “deployment strategy” for services build with EDRA. Because we decided some time earlier to host all our services within 1 instance of EDRA (even if they are built for different projects/applications) we encountered some issues when using the “deployment strategy” that come with EDRA.
We noticed the first issue when trying to install two services on our development server created by two different developers on their local machines. Both developers had an EDRA installation on their machine. On both machines the EDRA assemblies had a different “PublicKeyToken”, of course this caused all kind of problems when deploying these services to our central instance of EDRA. The services were both compiled against a different set of EDRA assemblies. Installing these two services on our development server hosting one instance of EDRA caused all kind of compatibility issues between the different “PublicKeyTokens” in the EDRA assemblies and publicKeyTokens in the configuration files.
To solve this issue we build our “own” release set of EDRA assemblies. These assemblies are the ones that will be used for every project that is using EDRA. Also we made some changes in the ‘CreateNewTemplate.swf’ script and the “ApplicationTemplate.sln” that is used in this script. We deleted the ‘ReferenceArchitecure’ enterprise template from the solution to make sure no EDRA code files are available for our developers. Further we made some changes in the “Deploy.swf” and “SetupHelpers.swf” script to support only using the compiled assemblies within the Visual Studio solution created by our new “CreateNewTemplate.swf” script.
All this is included in the image that we created for setting up a .NET development machine. After installing this image on a machine, the developer ends up with machine containing all necessary Microsoft development tools, all EDRA assemblies installed in the GAC and a shortcut from the start menu to our modified “CreateNewTemplate” script. So now our developers are ready to build their EDRA based services without first installing EDRA.
After defining how to use the EDRA framework we had to define a strategy for our development, test and production servers. We decided to go for the “two server” option. This means hosting the service interface and service implementation on different servers.
We created a list with all files necessary for the two different server types. So only the necessary assemblies are installed on the machine (GAC). The EDRA configuration file is installed on both machines. On the server hosting the service interface we tested the WebService and Remoting transport. On the server hosting the service implementation we tested the WebService and DCOM dispatching transport. All combinations worked perfectly fine.
We think that the work described above brings us a relatively simple way of deploying an EDRA based service on either our development, test or production server. All the developer has to deliver is the “message”, “business action”and “interface transport” assemblies. And of course some EDRA configuration settings that will be included in the EDRA configuration files on the servers by our server administrator.
We noticed the first issue when trying to install two services on our development server created by two different developers on their local machines. Both developers had an EDRA installation on their machine. On both machines the EDRA assemblies had a different “PublicKeyToken”, of course this caused all kind of problems when deploying these services to our central instance of EDRA. The services were both compiled against a different set of EDRA assemblies. Installing these two services on our development server hosting one instance of EDRA caused all kind of compatibility issues between the different “PublicKeyTokens” in the EDRA assemblies and publicKeyTokens in the configuration files.
To solve this issue we build our “own” release set of EDRA assemblies. These assemblies are the ones that will be used for every project that is using EDRA. Also we made some changes in the ‘CreateNewTemplate.swf’ script and the “ApplicationTemplate.sln” that is used in this script. We deleted the ‘ReferenceArchitecure’ enterprise template from the solution to make sure no EDRA code files are available for our developers. Further we made some changes in the “Deploy.swf” and “SetupHelpers.swf” script to support only using the compiled assemblies within the Visual Studio solution created by our new “CreateNewTemplate.swf” script.
All this is included in the image that we created for setting up a .NET development machine. After installing this image on a machine, the developer ends up with machine containing all necessary Microsoft development tools, all EDRA assemblies installed in the GAC and a shortcut from the start menu to our modified “CreateNewTemplate” script. So now our developers are ready to build their EDRA based services without first installing EDRA.
After defining how to use the EDRA framework we had to define a strategy for our development, test and production servers. We decided to go for the “two server” option. This means hosting the service interface and service implementation on different servers.
We created a list with all files necessary for the two different server types. So only the necessary assemblies are installed on the machine (GAC). The EDRA configuration file is installed on both machines. On the server hosting the service interface we tested the WebService and Remoting transport. On the server hosting the service implementation we tested the WebService and DCOM dispatching transport. All combinations worked perfectly fine.
We think that the work described above brings us a relatively simple way of deploying an EDRA based service on either our development, test or production server. All the developer has to deliver is the “message”, “business action”and “interface transport” assemblies. And of course some EDRA configuration settings that will be included in the EDRA configuration files on the servers by our server administrator.
1 Comments:
Some nice deployment issues:) But in the end it works again, nice job!
Do you make use of Virtual server? Very good tool, just create one image with everything you need and you can enroll it to all other developers/servers.
Post a Comment
<< Home