CMS deployment process from authoring to production...
Rcently I have been trying to finalise the deployment process from our CMS authoring environment to that of our shared production environment (which I talked about in a previous post).The manual process (as I see it) consits of the following tasks:
Authoring Server
1. Do a "Get Latest" from Visual Source Safe, for the up-to-date CMS ASP.Net code base.
2. Build the Visual Studio .Net solution
3. Using the Site Deployment Wizard, Export the Channel, Resource Gallery and Template Gallery structures of the authoring environment into an SDO
4. Create a compressed folder of the ASP.Net code and SDO file
5. FTP the compressed folder to the production servers ftproot
Production Server
1. Export current live CMS content strucutre to a backup folder
2. Move current live CMS ASP.Net code base to a backup folder (apart from our web.config, because of local variable settings)
3. Decompress compressed folder in ftproot
4. Copy new CMS ASP.Net code base to home directory of live virtual directory.
5. Delete existing CMS Content structure in Site Manager.
6. Using the Site Deployment Wizard, Import the authoring servers SDO and CMS content into the production environment
7. Rename top level channel and resource gallery to that of your host header (i.e. www.site1.com)
8. Regrant permissions to newly imported CMS content strucutre to existing Subscribers (i.e. annonymous users) rights group
Now in an ideal world, I would like for CMS to be able to automatically deploy both content and code base, between authoring and production environment, as soon as a new posting is created on the authoring server.
This isn't the case and as such (or is it?), scripts need to be generated and scheduled to accomplish same. How much can we automate?
Well if we take the authoring server first, steps 1 and 2, will be done manually anyway once the code base has been modified. Step 3 is possible either using .Net com interop or vbs/wsh scripts. The standard compressed folder functionality in Windows XP/2003 doesn't seem to be available from vbs/wsh via a windows API call. So with Step 4, we will need to use a command line compression utility like winzip, and call via a wsh shell command. Similarly with Step 5, a wsh shell command for "ftp -s scriptfile.txt" would work.
As vbs\wsh seems to be the common denominator, this would seem to be the best option, and to schedule it using NT Task scheduler.
Now onto the production server, step 1 as with the authoring server is possible in a few ways. Steps 2 and 4 are straight forward command line copies. Step 3 is again similar to the authoring server, in that a winzip command line will probably be best. Steps 5, 7 and 8 would be very straight forward if a web instance of the CMS CurrentHTTPContext was avaialable. But from a vbs/wsh, how would you do this? And finally Step 6 is possible in a couple of ways.
As you can see, the deployment process is not straight forward.
And my current questions include:
Apart from introducing massive licensing costs, does an automated process exist, to accomplish what I am describing, or is there a simple architecure change (say shared SQL) that would do it?
Can you call the publishing API from vsb/wsh, to rename channels, delete channels etc?
Is the standard Windows compressed folder functionality available from vbs/wsh or .Net?
Will the ftp wsh shell command work over a secure ftp connection?
Any CMS or WSH guru's out there? Anybodys thoughts on this would be greatly appreciated
posted by Graham Quinn @ 10:15 AM
5 Comments:
all of what you describe could be automated either via WSH or a automated build system such as ABS.
You can use PAPI via the ApplicationContext no problem to avoid issues with steps 5, 7 & 8.
no need to use the SD wizard - use site deployment scripts.
command line FTP doesn't support resume (AFAIK) never mind 'secure' ftp - but you can use a cheap third party com library for this, which will provide you with a much more robust solution should you really want to use FTP.
i've implemented a number of custom WSH solutions for deployment of CMS solutions, drop me a line if you could use some of this code. spence at harbar dot net
I am trying to export the channel structure along with all template galleries and resource galleries manually(using Export option in site manager) through Site Deployment manager. It is exporting the structure successfully but while importing the sdo file on another MCMS server it is exporting channels only. It is not exporting/showing the postings in the sub channels/templates. It is not giving any error also.
what could be problem. Please suggest if i need to do some extra settings.
Thanks
Got this finished a couple of months ago, but never had time to update my blog.
There was loads of what I called "cul de sac" development.
The deployment process was developed as 2 .Net C# Console Applications (1 called AuthoringServer and the other called ProductionServer), with 1 shared C# class library (namely Common).
Looks relatively straight forward, but here’s the problems that arose.
I looked at trying to use the FTP support in .Net or a 3rd party FTP client to ftp an entire folder of files and subfolders (i.e. SDO and ASP.Net code), but found that the standard .Net one is very limited, doesn't support secure FTP nor PASV mode. A 3rd party API for FTP did, but only individual files of specific formats, i.e ASCII or Binary. So you had to know the type of the file up front, this would be very hard with all the different file types within the ASP.Net code base.
Next I looked at zipping all content (SDO and ASP.Net) and then just FTPing that zip across to the production server.
Initially I looked at a Java class within the .Net framework that supports reading and writing zip files. (c:\windows\Microsoft.Net\Framework\v1.1.4322\vjslib.dll) But I quickly found that if one of your files you are writing to the ZIP is a binary files (e.g. JPG, GIF), it would write the ZIP ok, but when you go to read the zip using the same class libraries, it thinks its corrupt. I could open it with WinZip because it ignores the error headers. A solution on the web from Microsoft, says to use WinZip to read the ZIP written with the Java class. I don't think so.
Then as the last example mentioned WinZip, I decided to download the eval with the free command line add-on. And use command lines and create the ZIP that way, rather thatn use a mix and match of both the java and winzip. Everything worked fine.
Impersonation was the next important factor, so that you could paramertise the identity of the MCMS system or admin roles for access to the PAPI.
Once all development was completed, all that remained was to copy these 2 console applications to each sever, and using a batch file supply the relevant parameters. Using NT scheduler we then set it to run and certain intervals, the authoring server running at least an hour before the production server.
This is very much a summary of what was developed and omits a lot of details. If you want any more specific details, drop me a mail...
We use Beyond Compare to move physicla files beteen dev - stage - authoring and live. This works well and can be scripted (though we havent).
the correct architecture for the MCMS channel structure is a bit complicated when moving between servers but should not require you to change the channel name.
If you use a single website and use the map channel names to hostheaders on the live but NOT on the author you should be able to use the following:
Live: www.domain.com
author: author.domain.com/www.domain.com
This works well but yoou will need to create a virtual directory on the live site to get the images to work correctly.
Hi
I wonder whether you could help with a few mcms 2002 issues I am facing?
Post a Comment
<< Home