How do I unzip remotely during the automated deployment to our QA environment?

Question

I'm trying to figure out a way to automate the deployment to our QA environment. The problem is that our release is quite big, so needs to be Zipped, FTP'd and then Unzipped on the QA server. I'm not sure how best to unzip remotely.

I can think of a few options, but none of them sound right:

• Use PsExec to execute a remote commandline call on the QA server to unzip the release.
• Host a web service on the QA server that unzips the release and copies it to the right place. This service can be called by our release when it's done uploading the files.
• Host a windows service on the QA server that monitors a file location and does the unzipping.

None of these are pretty though. I wonder how others have solved this problem?

PS: we use CruiseControl.NET to execute a NAnt script that does the building, zipping and FTP.

Answer 1

Instead of compressing and un-compressing, you can use a tool like rsync; which can transparently compress data during file transfer. The -z option tells rsync to use compression.

But I assume you are in a Windows environment, in which case you could use cwRsync (which is "rsync for Windows").

Depending on your access to the QA box this might not be a viable solution. You'll need to:

• install the cwRsync server on the remote machine and
• allow the traffic through any firewalls.

Answer 2

At the last place I worked at, we had a guy write a Windows service on the CI box to do the unzipping. TFS Team Server finished the build and notified a service to zip the completed build and copy it to the CI box. The CI box picked up on the new file, and unzipped it. It may have been a bit heavy, but it worked well - and he was cognizant to log all actions to the event log, so it was easy to diagnose if a server had been reset and the service hadn't started.

Update: One thing that we would have liked to improve on that process was to have the service on the CI box check for zip files and uncompressed files that were older than x months, for purging purposes. We routinely ran out of disk space (it was a VM that we rarely looked at), and had to manually purge old builds when it happened.